stoplightio
Elements bundles several large libraries... why?
We are deploying stoplight elements via docker containers. I notice that a number of big-footprint modules - sentry and faker-js mainly are pulled in with stoplight. Why, and can we do something about it?
Context
Reasonably sized docker images.
Current Behavior
du -d1 -m
22 ./@stoplight
18 ./@faker-js
11 ./@sentry
That's 51MB just for stoplight.
Possible Solution(s)
Perhaps some of these things are real dev dependencies? Or should be peers for optional features?
Hey!
Thank you for reaching out.
We're aware the size of installed dependencies might indeed look a tad large, although in reality it's not that bad when the package gets bundled. Keep in mind that installed dependencies oftentimes contain irrelevant artifacts such as LICENSE, documentation or test fixtures, etc. - all of which wouldn't be loaded in the browser.
You can preview the approximate size using bundlephobia in case you're curious.
That being said, there's certainly a place for some improvements on our side.
Libraries such as fnv-plus or @sentry/browser are redundant in the context of elements, so these could be indeed wiped.
Some others, however, are quite vital to elements.
To list a few:
- @stoplight/mosaic is a UI library that we use to ensure consistency
- @stoplight/http-spec is an abstraction layer for OpenAPI v2 and v3.0 and 3.1 as well as Postman Collections (not supported by elements). In the future, adding another spec such as AsyncAPI would make it fairly easy to re-use existing UI components in Elements, since the interfaces would be similar.
- @stoplight/json and @stoplight/yaml - contains JSON/YAML parsers as well as various utils used by Elements.
Do feel free to reach out if you have any other concerns or questions. I'll keep the issue open so that we can stay in touch and make sure the issue in our radar.
We are deploying stoplight elements via docker containers.
Sorry to derail this thread, but: Is the Docker image public? I would like to use it too!
