Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct, but now we don't need to run the two commands in separate terminals, as yarn watch
should just work. I'm not sure if this a better workflow or not (I haven't tried it). It might be worth only mentioning yarn watch
, or softening the language of running the command in separate terminals.
Or we could leave it as it is now, your call.
bors delegate+
✌️ rehandalal can now approve this pull request. To approve and merge a pull request, simply reply with |
I only use the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r=@mythmon
Build succeeded: |
That's actually by design. There has been an open issue for Webpack for a long time to give it an option to watch but not build, and it would solve this exact case. There is even a PR for it, but it hasn't been merged. Is the double build actually slowing you down, or just wasteful? I wonder if we could make the second build basically a no-op if we tweak the caching or some other options. |
It's not really slowing me down at most times. It's just if I'm making certain kind of changes like to the webpack config where I need to restart it can sometimes be annoying. I'm not too concerned about it. |
Ah, ok. The second build doesn't block the extension starting, it's just noise. The first build, which is blocking in your case, is needed anyways. And watch mode rebuilds seem pretty quick to me. So the double build isn't making anything worse. It sounds like there might be some small benefit in trying to optimize our build times, but it's not a big deal. |
r?