# request npm — Deprecation Issue

**Link:** [https://github.com/request/request/issues/3142](https://github.com/request/request/issues/3142)

## Description

Before I go into the details and reasoning I’ll get straight to the point. **The most valuable thing `request` can do for the JavaScript ecosystem is to go into maintenance mode and stop considering new features or major releases.**

Apologies in advance to the other committers on `request` that have been doing their best to improve it, but it’s for the best.

## 2009

The first version of `request` was one of the first modules ever created for the Node.js ecosystem. For the first few years, `request` and Node.js evolved together, each learning from the other. As Node.js improved and migrated core interfaces so did request. As request adopted changes to the core http library and streams it also informed improvements like the `pipe` event and one of Core http’s many re-writes.

## npm

`request` was one of the first modules added to the npm registry. As npm grew so did dependence on `request`. Even now, when `npm` is used far more for front-end than back-end work, `request` remains one of the most depended on modules in the registry. As I write this, 41K modules depend on request and it is downloaded 14 million times a week.

The place `request` has in the Node.js ecosystem is no longer one of an innovator but of an incumbent. If you Google for how to do something with HTTP in Node.js the examples are likely to show `request` as the client and `express` as the server. This has two notably bad effects.

It’s much harder for new libraries accomplishing similar tasks to gain adoption because of the incumbent position `request` holds over the ecosystem. It’s also very hard to change request in any meaningful way as the change not only may not be adopted by the majority of its dependents but it would put it out of alignment with the thousands of tutorials online.