Closed wallentx closed 5 months ago
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
Package | New capabilities | Transitives | Size | Publisher |
---|---|---|---|---|
npm/electron-playwright-helpers@1.7.1 | filesystem Transitive: environment, shell | +13 |
433 kB | jjeff |
npm/source-map-loader@4.0.2 | None | +3 |
567 kB | evilebottnawi |
npm/thread-loader@4.0.2 | filesystem, shell, unsafe Transitive: environment, eval | +13 |
2.21 MB | evilebottnawi |
🚮 Removed packages: npm/electron-playwright-helpers@1.6.0, npm/lerna-audit@1.3.3, npm/lerna@7.1.5, npm/nx@16.7.2, npm/source-map-loader@4.0.1
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎
To accept the risk, merge this PR and you will not be notified again.
Alert | Package | Note | Source |
---|---|---|---|
AI warning | npm/untun@0.1.3 |
|
AI has identified unusual behaviors that may pose a security risk.
An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding.
Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.
If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.
To ignore an alert, reply with a comment starting with @SocketSecurity ignore
followed by a space separated list of ecosystem/package-name@version
specifiers. e.g. @SocketSecurity ignore npm/foo@1.0.0
or ignore all packages with @SocketSecurity ignore-all
@SocketSecurity ignore npm/untun@0.1.3
To provide a better description of what I'm exploring in this PR:
In November 2023, node started shipping with corepack
, as well as pnpm
, and yarn
(not enabled by default, but corepack enable
enables them), and they also claim they have no intentions to replace npm
as the default package manager. Both pnpm
and yarn
support management of monorepos by default, so you could ditch lerna
and nx
. Though, @seeden said he didn't want to shift away from npm
at the moment.
I was looking at build+install speed differences between using pnpm
, yarn
, and npm
. I also saw that the webpack usage - the longest running task during gui install - might be able to leverage thread-loader
for a speedup.
I was always bothered by the install time of the GUI, so I added a build:local
script to only generate locales that are on my system, and to also drop usage of cross-env
for when building locally.
It was Sunday and I wanted to learn a bit about new nodejs stuff, so I used this as an excuse, and also, my GitHub activity is full of crickets, so I felt anxious and needed to make some commits.
This PR can be ignored for the moment, since @seeden said he wants to stick with NPM, however, my findings from these changes when building on my phone did show a really good speedup.
main
: DNF. I got impatient and stopped the install at 27 minutes
wallentx/pnpm
: 19 min
So I might transform this PR to just the speedups if I can replicate them using npm
. But at the moment, I'm actually having issues with the webpack config on x86_64 for some reason
@wallentx, thank you for your PR. I understand that pnpm is faster, but we are using monorepo with a flat structure. pnpm creates a hierarchical structure, which is the main reason why you see many webpack issues during the build. Because of this, you need to be very careful with all package versions. You can easily end up with two different versions in your final bundle, which brings "crazy" unexpected errors across the application. We will save 10 minutes, but the development effort will take you a few other hours of your life fixing problems with versions. In terms of Yarn we would like to stay with standard npm for now. NPM added all needed features related to workspaces and everybody knows it because it was in the node js from the beginning.
Understood, and thanks for the explanation! I'll go ahead and close this, and if I can achieve any speedup just using thread-loader
, I'll make a separate PR for that.
Drafting monorepo management via pnmp - yarn v4 monorepo management PR coming shortly for comparison