RFC: Install size information #20427
Comments
|
My first thought is that in the front-end context many people will misinterpret this size as the size shipped to the browsers (which it usually isn’t). I wonder if there’s any way to preemptively clarify this. |
|
@gaearon I thought about that, too, but it's also not my job to make compression/minification decisions for users. Those are even more application-dependent than the unpacked size on disk. |
|
Thinking about this further: the main workflow that I imagine this would benefit is from folks doing |
|
I think I have some spare cycles to look at this this week. The I'm trying to think of any simple addition to your parenthetical and maybe something like '(+32 MB added to node_modules)' would add clarity, but I think there is also a user education piece to this. Perhaps there should also be documentation improvements clarifying how to calculate the build size, and maybe it could point to an article regarding how to measure the web app loaded in a browser context. What questions need to be addressed before I can start investigating/implementing? |
|
@strand documentation can be updated, but I think it's generally safe to assume the vast majority of people won't read this level of detailed documentation, and good CLI UX requires things be "obvious". The challenge of measuring "loaded in a browser" is much bigger, since it varies entirely depending on individual tool used to minify, bundle, etc, as well as all the configuration for whatever tool you pick. It's basically an infinite space, and bundling isn't something that npm does (or, tbh, will) get involved with. The If you're interested in implementing this, I'd suggest waiting a few days -- maybe look at this issue again this weekend or next week, after it's had time to get discussed a little, just so you're not getting thrashed around as we discuss potential issues. Implementation-wise, I believe this implementation will be pretty much what's laid out in the implementation section in the OP. It's not a lot of code, and most of the lego blocks are already in place for you, so this ends up being mostly glue work. There's the possibility of unforeseen implementation details, and I think I'm gonna have to ping the registry folks to make sure |
|
Makes a l 8000 ot of sense. The docs should be updated AND the CLI UX should ideally be so obvious that docs aren’t needed. I have some free time on Friday afternoon, so I’ll make this my open source Friday project, and may get a PR going, tho I’ll probably just spike out a potential implementation… Thanks for the initial guidance. 🤞🏼 I can grok this and fit the work into my regular schedule. |
|
@strand if you want to talk to us more directly, join the https://package.community Discord and pop into the npm channel! We hang out there for dev-related chats |
|
@gaearon I think some people might be confused. For example, users installing react-dom care about bundle size. This is an interesting problem I have been thinking about for some time and lead me to create https://github.com/styfle/packagephobia (you might be interested in looking through the README) An unsolved issue (which is probably outside of the scope of this RFC but worth thinking about) is: How can a user know if a package is meant to be installed as a devDependency (think test runner or CLI) or a front-end dependency (think react-dom). |
|
Hey y'all. We're switching around our RFC process, and so I've moved this RFC over to the |
This proposal introduces the idea of adding extracted package size information to the output summary for
npm install.NOTE
This is an RFC. It is not a finalized, accepted feature request proposal. I've laid out the general process of implementation, but please don't make a PR implementing it until we've had time to discuss this.
Problem
Right now, there's no built-in way for npm users to figure out the size impact of adding or removing a package from their tree. In the past, it would have been easier because you could just trace the nested tree -- but now, because of flattening and deduplication, it's not trivial to take into account how many new packages would be added by a particular install, and what their total impact would be.
Changes
npm installThe
npm installoutput will be changed such that total size information is included, and displayed in different ways depending on output mode:npm installThe default, human-readable view currently looks like this:
It will be changed to display size information like this:
Or when the net value is negative:
Even when both additions and removals have occurred:
npm install --jsonThe JSON format will add two things:
sizeandunpackedSizefield to each individualactionrecord, and asizeDeltafield that totals up all theunpackedSizechanges, in the toplevel:npm install --parseableThe
--parseabletab-delimited format will remain unchanged by default, to prevent potentially breaking parsers. Instead, the--long/-loption will be supported, which will add two additional columns next to each entry: the tarballsize, and theunpackedSize. It's up to users to add the numbers up themselves.Implementation Details
This would need to patch both the npm installer (in
lib/install.jsandlib/install/actions/extract.js), as well as add an extra field to thefinalizeManifestprocess inpacote(lib/finalize-manifest.js).npm installer changes
There are two changes to be made to the installer:
On the reporting side, update the three reporters (
printInstalledForHuman,printInstalledForParseable, andprintInstalledForJSON) inlib/install.js. You should be able to check_sizeand_unpackedSizein thechild.packagevalue, which holds the manifest for each installed package. Note: if any of the packages in the calculation are missing the_unpackedSizevalue and the current reporter isprintInstalledForHuman, this file size summary should be omitted altogether. This case will happen for legacy registries when usingnpm install --dry-run-- it will otherwise be calculated from actual extracted size.On the extract side, you will need to check if the
child.package._sizeandchild.package._unpackedSizeproperties exist. If they do not, you should set them based on metadata returned bypacote.extract().pacotechangespacoteneeds to do two things to support this:lib/finalize-manifest.jsshould be modified to get the compressed and uncompressed tarball size from package manifests, but only if they are available. They should be assigned to_sizeand_unpackedSizerespectively, and are present in thedist.sizeanddist.unpackedSizeproperties of the manifest.extract.jsandtarball.jsshould have their functions modified such that they return or emit size and unpackedSize as part of the metadata, where appropriate, after the operation has completed. This should be calculated from the actual data getting extracted (and may require changes tolib/extract-stream.jsas well aslib/with-tarball-stream.js.The text was updated successfully, but these errors were encountered: