[RFC]: stdlib API dependency explorer

[tejas-963]

Full name

Tejas Prajapati

University status

Yes

University name

Sardar Patel University, Gujarat

University program

Bachelors of Computers Application

Expected graduation

May, 2026

Short biography

I am currently a second-year undergraduate and will be entering my third year by the time the coding period starts. I am pursuing a Bachelors of Computers Application. My technical competencies include C/C++, HTML, CSS, JavaScript, Node.js, Tailwind and React.

My coursework includes a wide variety of subjects covering Programming Languages, Computer Organization, Computer Networks, Data Structures, Database Management Systems, Operating Systems, Object Oriented Programming, and so on.

Timezone

Indian Standard Time (GMT+5:30)

Contact details

Email: [email protected],
Github: tejas-936,
LinkedIn: tejas-prajapati-t369

Platform

Windows

Editor

My preferred code editor is Visual Studio Code (VSCode). I really like its wide range of extensions, built-in Git integration, and intelligent code suggestions. The user interface is clean, and it works well for both front-end and back-end development.

Programming experience

I learned C in school, then C++ and basic DSA in my first year of college. After that, I started learning web development with HTML, CSS, and JavaScript, Tailwind and React. I’ve built many small projects while learning these technologies, like logic based terminal projects, parameter convertor, Rock - Paper - Scissors, Guess the number, etc. with C/C++, and web based projects like calculator, weather app, clone sites, etc.

JavaScript experience

I learned JavaScript as part of my web development journey and have built many small projects with it, including a calculator, a weather app, clone sites, and several others. I also have a pull request in the stdlib repository for the package nanmprod.

My favorite feature is its flexibility especially how functions are first-class citizens. I love being able to pass functions around, use callbacks and stuff.

One thing I find tricky is the type coercion and some of the unexpected behaviors it can cause. These behaviors can lead to bugs if not careful. While it's something I’ve gotten better at handling, I still prefer being more explicit with types to avoid confusion.

Node.js experience

I’ve used Node.js mainly to run JavaScript code outside the browser and to set up simple backend servers during web development. While I haven’t built large-scale applications with it yet, I understand how to use npm for managing packages, create basic HTTP servers using the http module, and work with file systems. I'm also familiar with using Node.js scripts for automating tasks and contributing to projects like stdlib, which uses Node.js. I’m continuing to improve my Node.js skills and excited to work with it more deeply during this project.

C/Fortran experience

C was the first programming language I learned in school, and it helped me build a strong foundation in core programming concepts. While I haven’t worked on large-scale C projects, I’ve written several small programs and assignments during learning it, these included math-related problems, logic-building exercises, and terminal games such as “Guess the Number,” “Rock, Paper, Scissors,” and even a fun one to calculate your weight on other planets.

Fortran is not a language I’ve worked with yet, but I’m open to learning it if needed for the project. I’m confident that with my current programming experience and curiosity, I can pick it up quickly if needed.

Interest in stdlib

What really interests me about stdlib is its goal of providing a high-quality standard library for JavaScript and Node.js, similar to what's available in other languages like Python or C.

One feature is kind of my favorite you can say is the ndarray support. While exploring the codebase, I came across this idea: achieve ndarray API parity with built-in JavaScript arrays. I think it’s a really cool concept. After completing this project, I’d love to explore contributing to that idea as well.

And also, I appreciate stdlib’s focus on welcoming contributors of all experience levels. It’s a project I genuinely enjoy being part of and want to continue contributing to in the long run.

Version control

Yes

Contributions to stdlib

Open Pull Requests: stdlib-js/stdlib#6352

stdlib showcase

stdlib Showcase

I created a mini application that demonstrates a visual dependency tree using a few @stdlib packages.

• GitHub repo: stdlib-dependency-tree-mini
• Description: This app is a small scale demo of visualizing how different stdlib packages how they are connect, helping new contributors understand the structure in a more intuitive way.

Goals

Abstract

The goal of this project is to build an interactive dependency explorer for stdlib, making it easier for developers, especially new contributors , to understand how different packages relate to one another. When I first joined stdlib, navigating such a large and modular codebase was challenging. I often wish that there was a easy way to understand how packages were interconnected. This project is designed to address that exact need.

The explorer will allow users to:

• Visually explore dependencies between stdlib packages
• Navigate directly to each package’s documentation from the graph
• Access both global views (for example, entire namespace like @stdlib/stats) and local views (for example, direct dependencies of a specific package)

---

Detailed Plan and How It Will Work

Integration with the Existing API Docs:
The explorer will be embedded directly into relevant package documentation pages and optionally linked as a standalone tool for full-namespace exploration. This will be done by creating a new React component (<DependencyGraph />) in the www repo.

Data Pipeline:
During the build process, we will generate a JSON file containing the dependency graph using existing tools like @stdlib/_tools/pkgs/namespace. This file will then be consumed by the explorer to render the graph client-side.

Frontend Visualization:
The graph will be built using a library like Vis.js, chosen for its balance between simplicity, performance, and small bundle size. The explorer will support:

• Node zooming and panning
• Expand and collapse functionality for deep trees
• Tooltips for package names and descriptions
• Clickable nodes linking to package docs

Navigation:
Each node will serve as a hyperlink to the it's package’s API documentation. This creates a seamless bridge between the visual explorer and existing content.

Handling Deep or Complex Trees:
The tool will collapse deep branches by default and allow on-demand expansion to keep the graph clean and readable. We will also implement zoom and pan support and clustering for better navigation.

Accessibility and SEO (SSR Considerations):

• Ensure full keyboard navigation and screen reader support via ARIA roles and labels
• Render a minimal fallback view server-side (for example, a basic tree or summary list), then hydrate the interactive explorer client-side
• Include alt-text and tabular summaries for screen readers

Dependencies and Trade-offs:
We plan to use Vis.js as the main visualization library. Alternatives like D3.js or Cytoscape.js are more powerful but come with a steeper learning curve or heavier bundle sizes. Vis.js strikes a good balance and will be used with modular imports to keep the bundle lightweight.

Required Changes to www:

• Add a new component and possibly a global route (for example, /explorer)
• Modify templates to optionally embed local dependency views
• Update the static build process to generate dependency data files

Refactoring Scope:
Minimal and isolated to documentation rendering and build steps. Most of the project can be implemented as a plugin or module.

---

What I Hope to Achieve

By the end of the summer, I aim to deliver:

• A fully functional and visually clean dependency explorer
• Seamless integration with stdlib’s docs
• A tool that helps newcomers onboard faster
• A robust and accessible frontend that meets performance and usability standards
• A foundation for future enhancements (for example, search, filters, PR dependencies)

This project combines my interests in frontend development, open source contribution, and building tools that solve real pain points. It is not just a technical challenge, it is a chance to give back and make stdlib more beginner-friendly.

Why this project?

What excites me most about this project is the chance to combine my passion for web development with meaningful open-source contribution. When I first discovered stdlib, I was completely new to open source and navigating an industry-level codebase felt overwhelming. I remember thinking, "If only this were a little easier to understand, it would be so helpful for beginners like me." Building a visual dependency explorer feels like the perfect way to solve that exact problem making it easier for new contributors to explore and understand the structure of stdlib.

I’m also excited by the challenge of creating something that is both performant and accessible to so many peoples. Designing a visualization that remains responsive as the number of packages grows, while ensuring it works well for all users, is a great learning opportunity. On top of that, contributing a tool like this to a well-organized and impactful project like stdlib is something I’d be really proud of.

Finally, this project will help me grow not just technically, in terms of working with dependency graphs, optimizing rendering, and using libraries like Vis.js but also as a collaborative contributor in a real-world open-source ecosystem.

Qualifications

I believe I’m well-suited for this project because of my practical experience, technical skills, and strong willingness to learn. I’m already familiar with most of the core technologies used in stdlib, especially those relevant to this project.

As part of my contributions, I’ve a open PR for the @stdlib/stats-incr-nanmprod package, and I plan to continue contributing regularly to deepen my understanding of the codebase and its ecosystem.

What makes me a strong fit for this project is my firsthand experience as a new contributor trying to navigate a large and complex codebase. So I want to building a tool that can genuinely help others in the same position. I’m excited to take on the challenges that come with this project and see them as opportunities to grow both technically and as a contributor. I'm confident in my ability to learn, adapt, and deliver.

Prior art

Similar tools exist in other ecosystems, like npmgraph.js for npm packages, Webpack Bundle Analyzer, and pipdeptree for Python. These show that visualizing dependencies is valuable and feasible. However, stdlib doesn't have an integrated tool yet, so this project aims to bring that functionality directly into its docs, tailored to its unique structure and needs.

Commitment

I plan to spend around 15–18 hours per week may be more than that if needed during the 12 weeks of GSoC. I don’t have any other jobs or vacations planned, and I can manage the college work alongside this.

Before GSoC starts, I’ll keep exploring the stdlib codebase, contribute and try out some ideas for the dependency explorer. After the program ends, I want to keep contributing — fixing issues, improving the tool, and also working on other things.

Schedule

Assuming a 12 week schedule,

• Community Bonding Period:

  • Understand www repo and docs structure
  • Finalize tech stack
  • Plan integration approach
  • Setup environment and create test prototypes

• Week 1:

  • Parse and store package dependency data
  • Generate JSON for graph input

• Week 2:

  • Build basic interactive graph using dummy + real data
  • Test with Vis.js, experiment with performance

• Week 3:

  • Connect real dependency data to the graph
  • Add hover, zoom, and click interactions

• Week 4:

  • Integrate graph in API documentation pages
  • Enable node-to-doc navigation

• Week 5:

  • Make graph mobile-friendly
  • Begin accessibility features (keyboard nav, ARIA roles)

• Week 6:

  • Clean up code, write docs
  • Address feedback, finalize midterm deliverable

• Week 7:

  • Handle deep trees (collapse/expand, focus)
  • Keep layout readable

• Week 8:

  • Add search by package name
  • Highlight or focus graph section based on query

• Week 9:

  • SSR support for SEO
  • Ensure seamless integration with Next.js docs

• Week 10:

  • Full screen reader support
  • Improve keyboard controls and contrast

• Week 11:

  • Optimize rendering
  • Reduce bundle size if needed

• Week 12:

  • Final testing, polish
  • Submit code, write final report
  • Plan post-GSoC improvements

• Final Week: Project submission!

Notes:

• The community bonding period is a 3 week period built into GSoC to help you get to know the project community and participate in project discussion. This is an opportunity for you to setup your local development environment, learn how the project's source control works, refine your project plan, read any necessary documentation, and otherwise prepare to execute on your project project proposal.
• Usually, even week 1 deliverables include some code.
• By week 6, you need enough done at this point for your mentor to evaluate your progress and pass you. Usually, you want to be a bit more than halfway done.
• By week 11, you may want to "code freeze" and focus on completing any tests and/or documentation.
• During the final week, you'll be submitting your project.

Related issues

No response

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.