[RFC]: improve project supply chain security by bringing production dependencies in-house

[gkbishnoi07]

Full name

Gopi Kishan

University status

Yes

University name

Medhavi Skills University

University program

Computer Science in AI/ML

Expected graduation

2028

Short biography

I am a BTech student at Medhavi Skills University, with a strong background in software development and open-source contributions. I have hands-on experience working with languages such as JavaScript, TypeScript, React, Node.js, and C. I am currently learning C and enjoy refactoring code using it, finding it to be a very nice language. Additionally, I have experience with backend development, designing REST APIs, and working with databases like PostgreSQL and MongoDB. I am passionate about building scalable and efficient systems, with a particular focus on API design and improving usability in web applications. Outside of coding, I enjoy working on personal projects and contributing to open-source communities

Timezone

Indian Standard Time (IST),UTC +5:30.

Contact details

email: gkishan1kyt@gmail.com, github: gkbishnoi07

Platform

Windows

Editor

I prefer VS Code because it's lightweight, fast, and has great support for multiple languages. The built-in Git integration, debugging tools, extensions support and customization options make it my go-to editor.

Programming experience

I have experience with JavaScript, TypeScript, React, Node.js, GraphQL, PostgreSQL, and MongoDB.
I’ve created an emergency button and
a workout website for help to records data in workout name ForgeFit

JavaScript experience

I have worked with JavaScript on several projects, including web apps using React and Node.js. I enjoy how flexible and dynamic JavaScript is. It makes building interactive web applications fun

My favorite feature of JavaScript is asynchronous programming (async/await) because it makes handling API calls and background tasks smooth and efficient.

My least favorite thing about JavaScript is its dynamic typing. While it gives flexibility, it can cause runtime errors that are hard to track down, especially in bigger projects where type issues may not show up until later.

Node.js experience

I work in open source, where I build API queries and mutations. I have also designed REST API endpoints for querying and filtering data. Additionally, I create APIs that fetch organization data from the backend and display it on the frontend

C/Fortran experience

I’m learning C and i solved many issue by using it. I find it to be a very nice language with great control over performance. I don't have experience with Fortran yet, but I’m eager to learn it.

Interest in stdlib

What excites me about stdlib is its goal of building a fast and comprehensive standard library for numerical and scientific computing on the web. It has given me a deeper understanding of how mathematical equations and algorithms are implemented, turning textbook concepts into real-world applications.

Version control

Yes

Contributions to stdlib

Merged Work
I have contributed multiple pull requests that have been successfully merged. My main work has been in the stats/incr/* and stats/base/dists. This includes:

stdlib-js/stdlib#5139

stdlib-js/stdlib#5193

stdlib-js/stdlib#5260

stdlib-js/stdlib#5270

Open Work
stdlib-js/stdlib#6129

stdlib-js/stdlib#6140

GSOC Project
stdlib-js/stdlib#6170

stdlib showcase

Work in Progress

Goals

The primary goal of this project is to eliminate the current 14 external dependencies used in stdlib. The immediate targets for this project are dependencies such as:

debug
glob
resolve
minimist

These dependencies are simpler to replace and are prioritized for the initial stages of the project. More complex dependencies, such as acorn (for AST parsing) and readable-stream (for Node.js streams), will require more careful consideration, testing, and potentially ongoing maintenance due to their scope and complexity.

The project will proceed by first focusing on easier dependencies like debug, glob, and resolve, before addressing the more challenging ones such as acorn and readable-stream.

Why this project?

I'm excited about this project because it gives me the chance to make stdlib more secure and easier to maintain by removing external dependencies. I’m also looking forward to the challenge of building in-house solutions and learning more about packages and security in the process. It’s a great opportunity to deepen my skills in JavaScript, Node.js, and dependency management while contributing to an open-source project.

Qualifications

I have a strong background as a full-stack developer with experience in JavaScript, TypeScript, and Node.js. I’ve contributed to several open-source projects, working on both frontend and backend systems. Through this, I’ve gained hands-on experience in managing dependencies, optimizing performance, and improving security in large projects.

Prior art

The goal of reducing external dependencies has been widely recognized and implemented across various software ecosystems. Here are a few relevant examples:

Node.js Ecosystem:

Request to Axios/Native Fetch API: In the Node.js ecosystem, the move from the request library to axios or the native fetch API is a prime example. The native fetch API is now available in both modern browsers and Node.js, eliminating the need for external libraries for basic HTTP requests.

Smaller Utility Libraries: Many smaller utility libraries are being replaced by native JavaScript methods or custom-built functions, helping reduce unnecessary dependencies.

Open-Source Frameworks:

Frameworks like React and Vue.js focus on maintaining a minimal core. This allows developers to add only the features they need, reducing the reliance on third-party libraries and keeping the codebase more manageable.

Supply Chain Attacks:

The rise of supply chain attacks, such as the SolarWinds attack and malicious code injections in npm packages, has made it even more important to reduce external dependencies to safeguard applications against such risks.

Commitment

I am fully committed to this project and plan to dedicate 40 hours per week as a full-time contributor during the Google Summer of Code program. Before GSoC officially begins, I will spend time getting familiar with the codebase, planning my approach, and discussing implementation details with the community.

I do not have any major commitments like exams during the program, so I can focus entirely on my project. After GSoC, I plan to stay involved in stdlib, helping with maintenance, improvements, and community discussions related to my work.

Schedule

• Community Bonding Period:

  Understand the stdlib codebase and how dependencies are used.
  Discuss the approach with mentors and set up the development environment.

• Week 1-2:

  Identify and document dependencies to be replaced.

  Start implementing replacements for simpler dependencies like debug, glob, and resolve.

• Week 3-4:

Complete the replacements for debug, glob, and resolve.

Test and ensure they function properly with the rest of the stdlib codebase.

• Week 5:

  Finalize and test implemented replacements.

• Week 6: (midterm)

  Submit PRs and address feedback.

• Week 7-8:

  Work on more complex dependencies like acorn and readable-stream.

  Refactor stdlib to use in-house replacements.

• Week 9-10:

  Test all replacements for performance and compatibility.

  Remove any remaining external dependencies.

• Week 11-12:

  Complete documentation and finalize changes.

• Final Week:

  Submit the final project.

Future Work:

Upon completing the primary goal of reducing external dependencies in stdlib ahead of schedule, I plan to continue working on Project #90. I have already made significant progress on this project, which is outlined in my issue #6170. I will raise a pull request to showcase my work and am confident that I can complete it by leveraging the time saved from finishing the main project earlier.

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.

[gkbishnoi07]

CC: @kgryte @Planeshifter

[Planeshifter]

Thanks for creating a proposal! Your proposal mentions replacing dependencies like debug, glob, resolve, and minimist, but lacks specific implementation details. Your proposal would benefit if you would discuss current usage of these packages in stdlib and what key functionality you propose to port or re-implement.

The main focus should be on bringing in-house any production dependencies that our downstream users will end up installing when depending on stdlib. It is a lesser priority to bring in development dependencies. With this in mind, would you change anything about your proposed plan?

You identify acorn and readable-stream as more complex dependencies. Do you think it's worth to attempt bringing them in-house? If you had to substitute this part of the project for something else, what would you pick?

Have you thought about your testing strategy for your replacements?

[gkbishnoi07]

@Planeshifter Thanks for the feedback.

I will include more technical detail around those dependencies

Yes, based on that clarification, I would slightly adjust the focus of my plan. Initially, I was considering both production and development dependencies equally. But with the priority now clearly on production dependencies
So my main efforts will go into replacing runtime packages like acorn, readable-stream, debug, glob, resolve, etc.

Yes, I think replacing them is possible, but only if we focus on the parts that stdlib actually uses
If I had to swap out the work on acorn and readable-stream for something else, I’d use that time to work on another valuable task: upgrading ESLint to version 9.

I’ve thought about how I’ll test the replacements. My plan is to first look at exactly how each of the external packages is being used in stdlib. Based on that, I’ll write tests to make sure my versions behave the same way.

I’ll also add separate unit tests for the in-house replacements themselves to cover different inputs and edge cases. Once I plug them into stdlib, I’ll make sure all the existing tests still pass so nothing breaks.