Preserve log colors

[G-Rath]

Expected Behavior / Situation

Colors emitted in webpack logs are preserved

Actual Behavior / Situation

Colors are not preserved by webpack-nano.

Modification Proposal

It's a minor thing, but the colors make the logs easier to read:

vs.

[shellscape]

@G-Rath looks like your environment might have an issue with chalk and it's supportsColor method:

webpack-nano/bin/wp.js

Line 127 in 198bb13

const defaultStatsOptions = { colors: chalk.supportsColor, exclude: ['node_modules'] };

This might be a situation in which we need your help to debug. I'm unable to reproduce it on my end.

[matheus1lva]

Probably a problem windows related, because on @shellscape mac and on my linux machines, this doesn't happen.

I know some emulated terminals have problems to output some colors. Chalk under the hood uses the same support-colors that webpack-cli uses, which is strange, having such a difference between those two.

[G-Rath]

@shellscape probably, but that was why I made the issue, as it's a bug for my environment. Sorry about not mentioning I was on Windows - I had meant to do that.

I'm running Windows 10 Pro, and as my screenshots show, webpacks colors work fine 😉

Let me know what else I can do to help debug this problem.

[shellscape]

Cool.

webpacks colors work fine

You mean webpack-cli displays colors just fine 😉 We use chalk, and chalk uses supports-color under the hood. webpack-cli also uses supports-color

Are you sure that your config isn't messing with that value in some way? (Perhaps webpack-cli is overriding that?)

Give this a shot as well to make sure that the module thinks your env does in fact support color:

• $ npm install --global supports-color-cli
• $ supports-color
• $ echo $? - I'm not sure about this one on windows.

$? displays the exit code of the last command. If the exit code is 1 then that module thinks your env doesn't support colors.

Aside from all that, we probably need you to inspect that line 127 I pasted before, to see what the return value of chalk.supportsColor is there.

The value of whichever options are being passed to stats on this line

webpack-nano/bin/wp.js

Line 133 in 198bb13

const result = stats.toString(options.stats == null ? defaultStatsOptions : options.stats);

is probably relevant here too.

[G-Rath]

You mean webpack-cli displays colors just fine 😉

Actually, pretty sure I mean webpack - if webpack-cli is doing the color display, wouldn't that mean it'd have to parse the output provided by each compiler, and somehow figure out what needs coloring? But since the whole point of webpack-nano is to not use webpack-cli, and the output coloring is apparently expected to be the same, doesn't that mean the coloring is happening inside the compilers, which includes webpack?

Note that the coloring for awesome-typescript-loader is fine.

Are you sure that your config isn't messing with that value in some way? (Perhaps webpack-cli is overriding that?)

Naturally I'm not sure, b/c I don't know the full impact of every configuration setting on the packages using it. I do know that my config isn't weird or trying to be clever in anyway, so I'd expect it to work.

echo %errorlevel% is the Windows version of echo $?.

Mine echos 9009.

I'll take a look into logging the output of that line.

[G-Rath]

I added this line above the one you mentioned to webpack-nano:

log.info(supports color: ${JSON.stringify(chalk.supportsColor)});

The results:
⬡ webpack: supports color: {"level":3,"hasBasic":true,"has256":true,"has16m":true}.

Since webpack-nano & awesome-typescript-loader both have color, I'd say the issue might lie with webpack (and surrounding components)?

[shellscape]

This is 🍌 s. What's the value of (options.stats == null ? defaultStatsOptions : options.stats) on line 133?

[G-Rath]

That's the problem: I have stats in my config, which isn't merged, meaning colors is lost:

stats: { assetsSort: '!chunks' },.

Is there any reason why you don't merge those?

I can solve this on my end by specifying color: true, but personally I'd think it'd make sense to merge the two objects.

[shellscape]

Thanks for doing the dirty work there. That's really telling - we need a FAQ in the README for certain.

Is there any reason why you don't merge those?

Yes! I'm so glad you posted this issue.

So webpack-cli and webpack-command both do a lot of things that are opinionated. Turning on color for stats when it's not defined is one of those opinionated things. And because of that users have come to expect some opinionated things. In a twist, webpack itself does not default colors to true - https://webpack.js.org/configuration/stats/#stats.

Now with webpack-nano, I chose to leave out the opinionated stuff. We're solely passing along the config as-is to webpack, with very few adjustments. Providing default stats options is kind of required for webpack, otherwise the output is even less-pretty - that is really walking the line on not being opinionated. But if a stats setting is in the config, we don't want to screw with that. Its for the same reason there aren't a litany of command line flags. The mantra of the module is "Config should be done in config."

---

So after all that, I had thought that either supports-color was misbehaving, or that we were munging stats in some way. What's definitely an issue is that we're not using chalk.supportsColor correctly, as webpack expects a boolean (whereas chalk.supportsColor is returning an object). And then we need some documentation. All in all, this issue is a win and it'll make the module better. I'll try to get a change out to address all of that, but for now, you should explicitly define colors: true in your stats config.

[matheus1lva]

Interesting that on that screenshot I posted, I didn't have colors anywhere on my config, nor an argument on cli. Whatelse could it be?

[shellscape]

@playma256 if you didn't define stats options in the config, webpack-nano uses a small default set of options, which turns on color if supported.

[matheus1lva]

Oh, so nvm. Makes sense

[G-Rath]

Now with webpack-nano, I chose to leave out the opinionated stuff

I knew that was going to be your response :) I did notice that colors is false by default, and so on.

I'd argue that colors might be the one you should be slightly opinionated on, as like I said in the original post webpacks color-less output is very painful to try and read at a glance, and given that you already test if the terminal supports color, it makes for a great default, and saves the user from having to have an extra package in userland + "clever" logic in their webpack configs.

However I also understand that it's a very slippery slope, with as you said its walking a very fine line.

Ultimately, webpack-nano is looking to be a very cool & speedy package.

My only other problem/bug with it right now is that it doesn't seem to output anything indicating it's noticed a file change - it just seems to output a blank line? But I'm unsure if that's a problem sitting with webpack-nano, webpack-serve-plugin, etc, and I don't really have the time to make a minimal example repo for a bug report 😕 (tho I guess I could argue that as a feature)

[shellscape]

My only other problem/bug with it right now is that it doesn't seem to output anything indicating it's noticed a file change

Open a super simple feature issue when you get the chance, and just include a screenshot of (probably webpack-cli or webpack-command) what you'd like to see similar, and we'll have a look at it. I use this (webpack-nano) with webpack-plugin-serve almost exclusively, and when files change and webpack rebuilds, I see additional build stats. But you're right in that nothing indicating a filesystem change otherwise is output.

[G-Rath]

@shellscape I've made that issue as you requested (#3). It might actually be a feature for webpack-serve-plugin, as it's actually webpack-dev-middleware providing that functionality, instead of webpack-cli.

I use this (webpack-nano) with webpack-plugin-serve almost exclusively

Do you also use hmr almost exclusively? I've had a couple of minor bugs that I suspect are from it, but again I've not had the time to report due to the need for all bug reports to provide a minimal example repo^.

For me, setting hmr to false results in a client error, while when it is actually enabled it never works when I make actual code changes, instead just giving me Aborted because uC5Q is not accepted in the Chrome console, and then finally if I have liveReload set to true, it works better, but I usually get Error [ERR_STREAM_WRITE_AFTER_END]: write after end after every re-compilation in the build console (the build & everything works fine - it's just extra noise that I have to filter out when looking over the results).

I suspect that last one might be b/c the page reload means the socket discussions, but hmr still tries to use it, or something along those lines.

If you'd like to discuss these problems further, it might be easier take this to a chatroom or email-chain. Otherwise right now they're not preventing me from developing, and they might already be on your radar.

Thanks regardless 😄

(btw, I'm pretty sure these are webpack-serve-plugin bugs, rather than webpack-nano ones)

^: Random idea - it could be super helpful if there was a base minimal example repo that already has webpack-nano + webpack-serve-plugin setup with a super simple webpack.config that we could just fork & modify. Personally I think that'd make it a lot easier to provide minimal example repos for bug reports! It could also help serve as a just a minimal example of what you need to get going

[shellscape]

Apologies for the short reply, but I'm about to head to bed for the night. I do use HMR with WPS. There's a test fixture that's wired up to an npm script you can go off of, it's at /test/fixtures/simple/webpack.config.js and it works well. The other maintainers are also using it in a work environment pretty successfully right now too.

Head over to that repo and open a new issue (with a repo that's causing you trouble if possible) and we'll work through it.