Tldr; The Drupal project should offer more official tools under the @drupal namespace on NPM for JavaScript developers using Drupal in a Decoupled context. The Drupal API Client → project (funded by the community as part of the Pitch-burgh innovation contest → ) has built a series of packages that we believe should be considered for promotion to this namespace.
For Drupal to be friendly to JavaScript developers who are using Drupal as an API, Drupal as a project should not be completely un-opinionated in this context.
Part of this is a perception issue.
While it is clearly not the only indicator, representation on npm tells a story here. Searching for Drupal results in a somewhat confusing set of packages, and it is unclear what if any are provided by the Drupal project. Those who know to look for the Drupal organization will only see four narrowly focused packages.
A search for WordPress results in a client, and many packages under the @wordpress namespace. Much of this is likely driven by the block editor, but it still provides the perception that WordPress is serious about JavaScript. Searching for Contentful provides a clear set of utilities, including packages to help consume data from Contentful. Contentful may not be a fair comparison here, since it is a completely headless CMS, but that doesn't change the fact that developers familiar with Contentful may have the expectation that any CMS they work with should have an official set of packages for them to take advantage of. They expect to be able to ‘npm install’ Drupal.
Drupal’s current hands off approach results in practical issues as well.
When building decoupled projects that consume data from Drupal, fetching and managing that data is often handled via custom code. Writing that custom code often requires some knowledge of Drupal’s implementation of JSON:API or other Drupal API endpoints. While packages do exist to help with this, developers need to be aware of them, which may not be the case as they aren’t officially associated with the Drupal organization on npm. These solutions also have various advantages and disadvantages or are tied to a specific framework or library, which can make it more difficult to use the same solution across multiple projects.
We don’t want to limit or narrow the possible solutions in this space, but having no opinions isn’t good for the Drupal project either.
The Drupal API Client → is a set of JavaScript packages that simplify the process of interacting with common Drupal APIs. Most commonly, developers will use our JSON:API client to interface with Drupal's JSON:API endpoints, but we also publish a base API Client package that can be extended, a client for Decoupled Router, and may support other Drupal APIs in the future.
The Drupal API Client takes great care to be framework-agnostic and universal. It can be used:
With the recent completion of our commitment based on Pitch-burgh funding and the 1.0 release of our JSON:API client package, we believe the project is at a point where it could be considered for promotion to the @drupal namespace on NPM. We also believe that being selected for funding by the community also indicates community support.
Increased visibility for these packages will serve a few different developer personas.
As a result of this effort, these packages will be part of the @drupal namespace which will provide increased visibility. This will lead to more developers finding and using them, and hopefully improve the outside perception that the Drupal project is serious about modern JavaScript.
Making the decision to ‘promote’ a community project like this will also force us to answer some other questions that could be important for the future of non-PHP Drupal associated projects.
We expect promoting the these projects will have the following measurable results:
Active
Idea
As one of the maintainers on the Drupal API Client, it would be great to see this happen to give extra legitimacy to these libraries when searching for Drupal related tools on npm.
This makes great sense and will be a big step forward in signaling to js developers that Drupal is serious about supporting legit tools expected from a modern CMS.