Does stackblitz distort NPM statistics?

[glutengo]

First of all: Awesome work, I love this platform and I think it's a really great tool. I hope this wasn't asked by anyone else in the past, either way I didn't find a question or FAQ entry about it.
Let's consider I have a library which is published on NPM. I provide a demo for the usage of this library on stackblitz. To my understanding, when a user opens the demo on stackblitz, it will prepare and build the project which may include downloads from NPM. If this happened everytime a user opens the demo, it would - in some way - distort the NPM statistic for the library because it would give it quite a big boost because even potential users who only opened the demo would now count into the statistics.
I would like to raise these questions as a consequence:

• Does opening the stackblitz demo result in an increase of NPM downloads?
• If so, is there any sort of caching in place which throttles the number of downloads?

[gyoshev]

Stackblitz uses client-side fetching from content delivery networks that cache and serve NPM packages, such as unpkg. From the blog post on the Turbo package manager:

We recently rolled out a Turbo-specific CDN that hydrates any NPM package in one gzipped JSON request, providing massive speed boosts to package installations.

and

Every Turbo client runs standalone in-browser and automatically downloads the appropriate files on-demand directly from jsDelivr’s production grade CDN if a package fails to be retrieved from our cache. But what if jsDelivr goes down too? No sweat—it then switches over to using Unpkg’s CDN instead, giving you three separate layers of redundancy for ultra reliable package installations.

That means that the statistics will be skewed only by just a few requests, which are made by these services when they cache the packages. Given that the npm stats include automated bots and build machines, the impact of Stackblitz can be neglected.