Error: “Size Limit can't resolve fs” about size-limit

[ai]

We can do:

1. npm pack
2. unzip package to temporary dir
3. npm install
4. Check dir size

But we must to do it in separated project. Maybe package-limit?

[ai]

I have two news:

1. Size Limit was not designed for this use cases.
2. But I really like your idea. I will try to implement it. Unfortunately, it could take few weeks. I will add special option to ignore all Node.js modules and disable gzip and uglify.

Here is a temporary workaround:

1. Add browser: { fs: false } to your package.json. It will say for webpack to ignore this module.
2. Add gzip: false to Size Limit config since you are care about size on the disk.

Will like work for you until I will finding better solution?

[ai]

@styfle I very like the project. It will be more accurate than Size Limit since it will calculate also non-jS files. Do you have CI tool to run it in Travis CI?

[jaydenseric]

Do you run Size Limit on server-side project?

Yes.

Why do you care about size of server size project?

Because I am a responsible package author, and want to ensure my packages are lean and efficient. This is particularly important for consumers that use Webpack or Babel to process their server-side code; they don't want huge bundles or compile times.

[ai]

Interesting use case. So you want to use Size Limit to control how much file size your project will have in user's node_modules?

[Siilwyn]

Another use-case is for CLI packages, I'm currently searching for a way to keep the size in check. I found the module cost-of-modules which does the job put returns the size of all modules instead of only the total size. I've opened an issue about it: siddharthkp/cost-of-modules#51

[Siilwyn]

@styfle very nice service indeed! In fact I love it, awesome to see somebody made this. Sadly as you already mentioned it checks the size after it is published while I would like to check the size in PRs.

Also proposal here: styfle/packagephobia#88

Regarding the CLI tools:

• Cost Of Modules: rejected
• Bundle Size: does not include the total size, assumes a build 'dist.js'
• Package Size: bundles with webpack
• Size Limit: well... here we are :D

[ai]

I decided that at least for now, fs will not be part as default. It is much safer to explicitly define it in ignore or in browsers.

If we will have this issue again in the future, I can change my mind.

[ai]

Hi. This error happens because Size Limit try to make browser version of your project (packing it by webpack) and there will not be fs module in browser.

There is a multiple ways to solve the problem. I need to know more before give you AP advise.

Do you run Size Limit on server-side project? Why do you care about size of server size project?

[jaydenseric]

Yep! While being aware of the size of my package code is interesting, it is also interesting to check my dependencies are not a horrific burden for consumer’s node_modules.

[ai]

@Siilwyn 👍

[styfle]

If I could jump in here, I might have some relevant info...

I have done a lot of research in this area and listed many similar tools here: https://github.com/styfle/packagephobia#how-is-this-different

I wrote Package Phobia to find the npm install size of package and protect against dependency. You can even add badge to your README to keep the size in check.

I hope that helps 😄

[styfle]

@ai Thanks for the kind words 😄

You are correct that Package Phobia will calculate non-JS files too (its looks at everything published to npm including the README.md file).

I do not currently have a CI tool because of the architecture...

Package Phobia is actually downloading the data after it's been published to npm--a CI tool would probably want to run before you publish to npm.

In that case, it's probably more appropriate to add this type of feature in one of these existing CLI tools:

• Cost Of Modules
• Bundle Size
• Package Size
• Size Limit (this one 😸)

[styfle]

Package Size does have an issue open for this so I think the author might be interested: egoist/package-size#16

[styfle]

Also note that npm actually has the concept of a publish "dry run".

They call it npm pack.

For a "dry run" that does everything except actually publishing to the registry, see npm-pack, which figures out the files to be included and packs them into a tarball to be uploaded to the registry.

Now this size is compress so it will be smaller than what Package Phobia reports (which is the uncompressed size) but I think the comment here explains pretty well how to find the uncompressed size.

[Siilwyn]

npm pack does not include the node_modules and yeah I've seen that comment since I created that issue. :D It's not perfect though since this will include development dependencies too, unless you would ofc. remove the node modules and only install the normal dependencies beforehand on the CI.

Maybe I should create a package for it to re-use it in other projects... but that's why I thought maybe a CLI tool for packagephobia makes sense.

[jonathantneal]

I am having a similar issue with the same error message. I have only 2 files, index.js and package.json:

module.exports = require('mdn-browser-compat-data');

{
  "scripts": {
    "test": "size-limit"
  },
  "devDependencies": {
    "mdn-browser-compat-data": "0.0.85",
    "size-limit": "^1.3.7"
  },
  "browser": {
    "fs": false
  },
  "size-limit": [
    {
      "path": "index.js"
    }
  ],
  "private": true
}

Running npm test produces the following error:

 ERROR  Size Limit can't resolve
        fs
        in /test/node_modules/mdn-browser-compat-data

It may be important to note that mdn-browser-compat-data is a JS file which uses fs to load all of its data (see https://unpkg.com/[email protected]/index.js).

However, this fools tools like BundlePhobia into believing the library is only 975 bytes, minified and gzipped (see https://bundlephobia.com/[email protected]).

---

Right now, my workaround is to write the export of mdn-browser-compat-data to a new JSON file and to run size-limit against that:

require('fs').writeFileSync(
  'index.json',
  JSON.stringify(
    require('mdn-browser-compat-data')
  )
);

  "size-limit": [
    {
-      "path": "index.js"
+      "path": "index.json"

Then, running npm test produces the following result:

  Package size: 363.96 KB with all dependencies, minified and gzipped
  Loading time: 7.3 s     on slow 3G
  Running time: 7.7 s     on Snapdragon 410
  Total time:   15 s

And I would say 363.96 kilobytes is not quite the same as 375 bytes. 😄

[ai]

1. Can you try to add ignore: ['fs'] to Size Limit config
2. 975 bytes is a strange number for library with data. How your tool will work it browser? Do it load JSON by require?

[jonathantneal]

1. Yes, adding the ignore config resolves the error.

{
  "scripts": {
    "test": "size-limit"
  },
  "devDependencies": {
    "mdn-browser-compat-data": "0.0.85",
    "size-limit": "^1.3.7"
  },
  "browser": {
    "fs": false
  },
  "size-limit": [
    {
      "path": "index.js",
      "ignore": [
        "fs"
      ]
    }
  ],
  "private": true
}

After making this change, running npm test produces the following result:

  Package size: 2.21 KB with all dependencies, minified and gzipped
  Loading time: 45 ms   on slow 3G
  Running time: 101 ms  on Snapdragon 410
  Total time:   145 ms

2a. Yes, 975 bytes is a strange number for a library with data, especially when size-limit ignored the fs statements and still reported 2.21 kilobytes.

2b. My tool is not necessarily intended for the browser. Instead, like caniuse-lite, it is intended for other tooling, which could be used in a browser. For now, I am mostly interested in producing a smaller version of mdn-browser-compat-data that uses browserslist compatible browser names to reduce the size and complexity required to use that data with other tooling, namely PostCSS.

2c. In mdn-browser-compat-data, the data is loaded with fs. I’m not sure how it will work for my tooling yet.

[ai]

1. I will think about adding fs as default ignore.
2. You can use --output-bundle to get output JS and see what webpack put there