On Thu, Oct 1, 2020 at 12:50 PM Andreas Gerstmayr <[email protected]> wrote: > > Hi! > > [starting a new thread, I guess my last reply to another thread got lost] > > I'm one of the maintainers of Grafana in Fedora. > > Latest Grafana has: > > $ du -sch node_modules > 1.8G node_modules > > Some of the largest dependencies: > > $ du -d 1 -am node_modules | sort -n -r | head -n 20 > 1760 node_modules > 291 node_modules/@storybook > 85 node_modules/@babel > 73 node_modules/monaco-editor > 66 node_modules/@types > 58 node_modules/@microsoft > 55 node_modules/typescript > 43 node_modules/@jest > 38 node_modules/@svgr > 29 node_modules/jest > 28 node_modules/@antv > 26 node_modules/jest-runtime > 23 node_modules/react-icons > 21 node_modules/cypress > 19 node_modules/react-dev-utils > 19 node_modules/less > 19 node_modules/@icons > 19 node_modules/concurrently > 18 node_modules/rxjs > 18 node_modules/listr > > $ ls node_modules | wc -l > 2022 > > Compressing the node_modules folder using zstd: > default level: 183 MB > zstd level 19: 111 MB > > How can/should we bundle that? Is this size acceptable for a SRPM? > > Bundling it would allow us to build the frontend and run the frontend > tests as part of the spec, and we can apply patches properly (without > (re)generating anything locally). Most of the patches at least, in case > some security patch requires an upgrade of a npm dependency, we also > need to recreate the vendor tarball. >
It's fine for SRPMs, we have had larger for other things. I know of cases where entire VM disk images were added as sources in SRPMs, making them ridiculously large. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ nodejs mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
