npx size-limit throws error in github action but not when executed manually

[natterstefan]

Hi @andresz1,

thanks for the great work you published. Looks really promising and I might create a PR for some README improvements. During setup, I had some troubles, which might be resolved by some tweaks in the README.

Independent of that, I have still trouble setting it up (see my checks here).

I get the following error:

But when executing it on my computer, everything's fine.

Do you know what's happening or point me in the right direction, please?

Thank you ✌️

[andresz1]

Hi @natterstefan

Thank you! 😄sure, it would be great if you could create a PR to improve the README. About the error I'll take a look and come back to you ASAP

Thanks

[natterstefan]

Thank you! :) Please, let me know if I can help.

[andresz1]

Hi @natterstefan

I found the problem, when executing npx size-limit --json the expected stdout is a json. Since there are some messages before the actual output (the i [alt] ...) of size-limit the JSON.parse is throwing an error.

Can you try adding silent option as true to awesome-typescript-loader and let me know if it works please. I think it would.

{
  exclude: /node_modules/,
  test: /\.(t|j)sx?$/,
  loader: 'awesome-typescript-loader',
  options: {
      useCache: true,
      silent: true, // ⬅️change here
  },
}

This silent option could also be only set when executing the action with an env variable. Nevertheless, I'm wondering if the action should handle these cases or should this be pointed out in the README 🤔

Let me know your thoughts! Thanks

[natterstefan]

Hi @andresz1,

thanks for the helpful hint, where and how to resolve it.

You can see the difference between turning on the silent option here:

(left: with silent: false - right: with silent: true)

This resolved my issue (see run). Nevertheless, I'm going to migrate to ts-loader. Should've done this in the first place.

I'm not sure yet if this should be handled by the action, as you never know what build system the user of the action has. IMHO it might just be enough to have a "Troubleshooting" section in the README. Every new issue can be documented there with a "how to fix" it.

[andresz1]

Hi @natterstefan,

Cool 🎉thank you! I think that adding a Troubleshooting section would be a nice idea. I'll add this case there (this can only happen if you provide a custom webpack config). Yep, using ts-loader is the right move 😉Feel free to open a PR if you want to improve the documentation!

Thanks again!