You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As noted in openculinary/company#9, we may want to reduce reliance on Microsoft-provided services. Currently this would include at least GitHub -- for source code hosting -- and NPM -- for retrieval of JavaScript dependencies for development, continuous integration, and production installs/deployments.
Describe the solution you'd like
Some free-and-open-source software ecosystems provide multiple independent mirrors of their source code and/or binaries. Operating a mirror isn't zero-cost; storage is required to store the content, and bandwidth is required both to synchronize with selected origin(s), and also to distribute the content to users (the latter of these likely to be the more significant cost in many cases).
NPM is provided at no cost to users, and to my knowledge isn't a charitable institution, so it seems likely that they sell or otherwise use data about usage patterns. As a well-known provider of JavaScript packages, they also provide a level of trust to the community -- I would estimate that using other sources of NPM dependencies could often be treated as a signal of lower-trustworthiness by manual and perhaps some automated technical dependency reviews.
That said: all the content is JavaScript plaintext code, and the total size of our node_modules install directly is ~225MB currently (30fc111) -- heavily weighted towards a few dependencies that are ~9.5MB+. This is a vast superset of the code shipped in the production application; approximately 1.4MB of JavaScript code is produced as reported by du -csh public/*.js after a local build (also at 30fc111).
I'm not certain yet what approach to select, but will describe a few possibilities in the 'alternatives considered' heading.
Describe alternatives you've considered
Vendoring all of the relevant code into our source code repository could be one option.
Finding NPM mirrors could be another option.
Spinning up our own mirror of NPM may be another possibility (I'm unaware yet whether software utilities exist to achieve this).
Switching to distribution-packaged JavaScript dependencies might be an option -- but introduces further constraints, and arguably only pushes the dependency retrieval/review/management work to other people, perhaps not ideal socially.
Do nothing, if we can convince ourselves that the existing situation is acceptable.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
As noted in openculinary/company#9, we may want to reduce reliance on Microsoft-provided services. Currently this would include at least GitHub -- for source code hosting -- and NPM -- for retrieval of JavaScript dependencies for development, continuous integration, and production installs/deployments.
Describe the solution you'd like
Some free-and-open-source software ecosystems provide multiple independent mirrors of their source code and/or binaries. Operating a mirror isn't zero-cost; storage is required to store the content, and bandwidth is required both to synchronize with selected origin(s), and also to distribute the content to users (the latter of these likely to be the more significant cost in many cases).
NPM is provided at no cost to users, and to my knowledge isn't a charitable institution, so it seems likely that they sell or otherwise use data about usage patterns. As a well-known provider of JavaScript packages, they also provide a level of trust to the community -- I would estimate that using other sources of NPM dependencies could often be treated as a signal of lower-trustworthiness by manual and perhaps some automated technical dependency reviews.
That said: all the content is JavaScript plaintext code, and the total size of our
node_modules
install directly is ~225MB currently (30fc111) -- heavily weighted towards a few dependencies that are ~9.5MB+. This is a vast superset of the code shipped in the production application; approximately 1.4MB of JavaScript code is produced as reported bydu -csh public/*.js
after a local build (also at 30fc111).I'm not certain yet what approach to select, but will describe a few possibilities in the 'alternatives considered' heading.
Describe alternatives you've considered
Additional context
N/A
The text was updated successfully, but these errors were encountered: