Add concurrently to show prefixes for server/webpack and less output from webpack

[AlMcKinlay]

No description provided.

[astorije]

This effectively removes all information from the Webpack output:

$ npm run build
> webpack
   332 modules

I know you have #1942 that improves output of npm run start-dev but it doesn't fix it for npm run build and npm run watch. I would not include this change.

[astorije]

I'm not sure we need this. All TL outputs already start with <timestamp> [<log level>] so in a way we know what's TL and what's Webpack.
Not opposed to it though, but we would need a few changes:

• It currently removes all colors/styles in our CLI outputs so things like 2018-01-07 04:11:35 [INFO] Available at http://0.0.0.0:9000/ in private mode appear in all white (muting important information). I haven't looked too much into concurrently, but I wouldn't be surprised if there was a way to pass it a flag to force colors or something

• concurrently and npm-run-all kind of duplicate each other as they solve similar issues. It would be better if we could use one or the other. npm-run-all has the --print-label flag that acts similarly to the colored prefixes of concurrently, except that:

  • fix: colorize tasks names sequentially instead of by hash mysticatea/npm-run-all#115 has not been released yet, and since "start".length === "watch".length, both have the same color, lol! Scratch that, I'm not sure why they have the same colors, but their PR will fix that once released anyway.
  • Same issue as concurrently for colors other than the labels. That can be solved by adding --colors to webpack --watch, but for us, we need a new --colors option that forces colors.enabled = true; on non-TTY or something so this isn't free.

[astorije]

Interesting, authors of all these packages have been saying they want to all stop theirs and contribute to a single npm-run-all package. It doesn't seem like there is much efforts currently, but mysticatea/npm-run-all#10 (comment).

[astorije]

but for us, we need a new --colors option that forces colors.enabled = true; on non-TTY or something so this isn't free.

Done in #1948 if we want this.

[AlMcKinlay]

Yeah, I know it removes most of the output, I did that deliberately. Do you actually find the list of modules helpful? I definitely don't, it's just noise to me. I was trying to clean it up a bit and make the interface better for dev.

The reason I used concurrently is that you can't specify the names and colours of the prefixes in run all (and as mentioned, they were the same colour) also, I was pretty sure (I need to double check this) that the output was still coloured using concurrently. I am not looking at it just now (will check on Monday) but I'm pretty sure it did.

I wanted the prefixes and the minimal webpack logging because I have easily missed server logs in amongst all the noise. If no one else has this issue, then that's fine, I'll do something locally. But I thought I would share my ideas for fixing that. It is a real issue I have come across, it's not like I just randomly decided to do this for no good reason.

As for having both... Yeah, the reason I didn't change the other to concurrently is that concurrently doesn't have a way to aggregate the outputs yet. I know it's not great adding another dependency, but it is only a Dev one.

[xPaw]

@YaManicKill Is this PR an alternative for webpack dashboard? I certainly don't find dashboard useful because it takes more space for all the bundle information (compared to just the stats that webpack spits out).

[astorije]

Do you actually find the list of modules helpful?

Definitely useful. Maybe not all of it, but most of it. It is useful to know what happens, which asset is part of the build (especially in watch mode where it tells you exactly which file is being changed and reloaded), what is the size of the bundle (telling you if a prod build is indeed correctly prod, if something is in the vendor bundle as it should be, etc.). Also nice to have the compilation time IMO.

It can be noisy at the first run, but in watch mode, it's not adding much at all.

Looking at this doc and the things I personally don't need, I'm fine doing hash: false, version: false, assetsSort: "name" (if I understand this correctly, though it doesn't remove anything).
That only removes 2 lines though, but I think I see value in all others. Considering changing a single file in watch mode is 10-line long, saving 2 lines is not so terrible.

The reason I used concurrently is that you can't specify the names and colours of the prefixes in run all

Specifying colors doesn't matter, but custom labels yes, I agree. But not a big deal for us at the moment (because start and watch are informative enough). It could be if we add options/arguments in the start-dev script, so mysticatea/npm-run-all#121.

(and as mentioned, they were the same colour)

That will be in the next release of npm-run-all so I'm not too worried.

also, I was pretty sure (I need to double check this) that the output was still coloured using concurrently.

This is not npm-run-all or concurrently specific though, and addressed in #1948.

I wanted the prefixes and the minimal webpack logging because I have easily missed server logs in amongst all the noise.

I have to admit that I use 2 tabs most of the time for npm start and npm run build. It's actually useful to restart them individually (when working on the server or the client only, can let the other one running just fine and only look at relevant logs), so stats: "minimal" is affecting this quite a lot, as there is no Webpack log to look at anymore.

Yeah, the reason I didn't change the other to concurrently is that concurrently doesn't have a way to aggregate the outputs yet. I know it's not great adding another dependency, [...]

I really think that we can have all that by just using npm-run-all with minor compromises, or just one extra feature (and another release) from them. Also I'm still hoping all these authors will finally get together and merge all their projects lol.

[AlMcKinlay]

Yeah, sorry, I should have explained about the 2 PRs.

I had ideas for both of them, I would like both of them, but I totally understand that others might, so I put them up as 2 different things and we can take 1, 2, or neither. If they won't be useful to others, I'll just keep them as local changes. Will close #1942 as clearly no one wants it. No hard feelings.

Now, back to this one, which I'm going to fight a bit more :-P

Definitely useful. Maybe not all of it, but most of it. It is useful to know what happens, which asset is part of the build

I'm struggling to see how you can use this. I find the errors useful, I find it useful knowing a build just happened, and that's it. I don't find it useful seeing a list of the modules because I either already know what I just edited, or I don't care. minimal still shows when it builds, and it still shows errors. Everything else is just noise IMO.

But not a big deal for us at the moment (because start and watch are informative enough)

Oh definitely not. "start" and "watch" ... they mean something to us because we know the name of the scripts. But to new developers ... it'll take some figuring out to know what they mean. I think the custom labels is more important than the colours being different.

Specifying the exact colours doesn't massively matter if it chooses sensible colours. I chose yellow/blue because it's one of the better combinations for colour blindness which is obviously a good thing to think about.

But yeah, the colour is not a big enough reason to choose concurrently, I accept that.

This is not npm-run-all or concurrently specific though, and addressed in #1948.

It appears that webpack is in colour, but the server isn't in colour when run through it. I turned off minimal, and get colours from the webpack bit. I've not looked at that PR yet though.

so stats: "minimal" is affecting this quite a lot, as there is no Webpack log to look at anymore.

Alright, fine. I guess I'll just make that change locally (boy, that'll be a fun one to figure out...) but I really don't get how they are useful. But to each their own, I guess.

I don't know why we have start-dev if people don't think it's a useful one at all.

I really think that we can have all that by just using npm-run-all with minor compromises, or just one extra feature (and another release) from them.

¯\_(ツ)_/¯ I don't think that adding another dependency for this is a problem, as it's only a dev dependency. It doesn't increase our production size at all. I think the advantages we get from concurrently are definitely worth it.