feat: support hot module replacement (HMR) #457

cletusw · 2017-03-09T17:07:58Z

Fixes #30

Based on #89, https://github.com/TrejGun/extract-text-webpack-plugin/

jsf-clabot · 2017-03-09T17:08:01Z

All committers have signed the CLA.

cletusw · 2017-03-09T17:09:40Z

index.js

@@ -285,7 +292,7 @@ ExtractTextPlugin.prototype.apply = function(compiler) {
 				callback();
 			}.bind(this));
 		}.bind(this));
-		compilation.plugin("additional-assets", function(callback) {
+		compilation.plugin("before-chunk-assets", function() {


Without moving to an earlier hook, the %%extracted-file%%, etc. replacements wouldn't take the first time around.

Please add a comment and ideally a test to cover that.

Comment added.

How would I do the test? It looks like there aren't any existing tests that check the contents of the JS file from which we're extracting. I could probably add the entire built file to the expected directory, but then it would break every time webpack updates the prologue code.

Maybe the question is what's worth testing. It could be possible there is no good way just yet.

this change is the source of problem I mentioned in #457 (comment)

@cletusw also, because of changing additional-assets to before-chunk-assests webpack does not produce source maps anymore :(
I am not sure how to fix this..

@mieszko4 Yeah, I don't know enough about webpack or this code to know why one hook works and not the other, I just tried it on a whim and it fixed HMR. Since the maintainers are not planning on merging this PR I'm not inclined to work on it any further. Feel free to make a PR to my fork if you can come up with a good solution and I'd be happy to look at it!

@cletusw I would help but unfortunately I do not know enough about webpack either..

@cletusw by the way I was able to get "additional-assets" to work so one hook could be used: https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/blob/master/index.js#L331

To begin with I did it exactly as you did with both "before-chunk-assets" callback and "additional-assets". In my case it was worse because I ended up duplicating a lot of code between the 2 callbacks.

Eventually however I went back and give it a try with the original callback and it worked. To be honest I'm not even sure what was different. My guess is it had to do with this line:

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/blob/master/index.js#L377

where I essentially overrode the _cachedSource source, thereby hopping over any limitations in what you can do in each callback. I think likely once the source is cached it's sealed to future callbacks, and what I did to stripe out css injection (so that one of my 2 types of javascript chunks doesnt waste bytes having css in it) overrode that.

Basically what I did is likely a hack and not the way the designers of webpack would do this, which is why it's imperative they chime, examine the state of affairs, and give direction before merging things back into ETWP and risking incompatibility and other errors to its large userbase. And to be honest, I also think the plugin should be re-written from the ground-up. No offense to anyone, but it's impossible to understand what this code is doing without hours and hours of research (and I did just that; days and days of playing with it; I'm ashamed to say 2 weeks, 4 hours a day). The code is procedural with huge methods. No pure functions--and by that I mean these functions are sharing state/variables all over the place. It needs to be broken into many smaller well-named pure functions so anyone has any hope of understanding it. I also don't understand why no line breaks are used--there are no logical groupings of related code. To be sure, half the problem is that it was my first time delving into the in-memory structure representing your bundle, but no punches were pulled to make it readable to anyone without in-depth knowledge of Webpack. I'm not sure if the whole codebase is like this, but I'm seeing it's written in plain js with no transpiler. Not that transpiling is the save-all solution, but basically the code could stand to being upgraded to learning from idiomatic best practices over the last 2 years. I love webpack, but after looking at what was going on underneath the hood in a few of these plugins, I'm basically shocked. That it all works is a miracle. I think just what we're hearing in this issue shows how scared people are of dealing with its codebase. Like no other popular codebase in Reactlandia, everyone in the back of their head intuits that only @sokra 's knows how to deal with it. That's why this past year when other people stepped up it was so apparent that it was a big deal, i.e. something that needed to happen that was hard to happen. I assume they still have growing pains for days. A huge codebase was built by one person in an antiquated procedural style that does everything including the ceiling fan. There's no other way to put it. Hats off to @sokra for gluing this all together and making it work. But Webpack 3.0 is gonna need a major refactoring if it doesn't want to get beaten out by a team that takes all its lessons and does it more extensibly before it's 4.0. That all said, I haven't examined 95% of the code. I'm mainly going off a few plugins. So if they are anomalies, great! I don't know what else to say. I only share this because I think it needs to be heard. Maybe it's said a bunch elsewhere--I dunno, I try to stay focused in application code as much as possible vs. building/bundling. Everybody knows bundling/building is not sexy and fun to do--thats why I have nothing but profound appreciation that @sokra ever built this. ...anyway this is just a plugin; forget saving the world; this particular plugin should be built from the ground-up. If it was, the challenge of getting our PRs merged wouldn't be the problem it is. At the very least the person that built it simply should write a bunch of comments in the code.

@faceyspacey I hear you. I think even Tobias agrees that the current implementation of the plugin is a hack. Note that webpack-defaults gives a transpilation step and makes it possible to rewrite a lot of code in a newer style. There's still the problem of legacy as you definitely don't want to break anything but it's a step to the right direction at least.

cletusw · 2017-03-09T17:10:50Z

@bebraw Here's my attempt at adding HMR. Can you review? Thanks.

codecov · 2017-03-09T17:11:42Z

Codecov Report

Merging #457 into master will decrease coverage by 9.11%.
The diff coverage is 92.85%.

@@            Coverage Diff             @@
##           master     #457      +/-   ##
==========================================
- Coverage   90.38%   81.26%   -9.12%     
==========================================
  Files           6        4       -2     
  Lines         364      347      -17     
  Branches       77       73       -4     
==========================================
- Hits          329      282      -47     
- Misses         35       65      +30

Impacted Files	Coverage Δ
index.js	`80.82% <100%> (-10.21%)`	❌
loader.js	`84.33% <83.33%> (-6.14%)`	❌
ExtractedModule.js	`86.48% <0%> (-8.64%)`	❌
schema/loader-schema.js
schema/validator.js

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75cb09e...360c155. Read the comment docs.

bebraw · 2017-03-09T17:34:54Z

@msuperina @jantimon Do you want to give this a go and let me know what you think? HMR for extract-text-webpack-plugin is here. 👍

Jessidhia · 2017-03-10T04:19:34Z

hotModuleReplacement.js

+        var hrefUrl = styleSheets[i].href.split('?');
+        var href = hrefUrl[0];
+        var hash = hrefUrl[1];
+        if (hash !== compilationHash && href === document.location.origin + publicPath + outputFilename) {


This will definitely break with different-origin public paths, but then again hot reloading overall wouldn't work in that case either.

location.origin is also not available in IE.

Fixed the location.origin problem.

Jessidhia · 2017-03-10T04:22:17Z

loader.js

 module.exports = function(source) {
 	if(this.cacheable) this.cacheable();
-	return source;
+	// Even though this gets overwritten if extract+remove are true, without it, the runtime doesn't get added to the chunk
+	return "if(module.hot){require('" + extractTextPluginHmrRuntime + "');}\n" + source;


This and the other string concatenations could be template strings.

Is there any objection to using modern syntax in files that haven't yet been "converted"? I don't really see a reason to wait until a conversion; it's not like all features have to be adopted at the same time and with 100% coverage.

Agreed. A string template would be far neater. Node 4 too.

I was originally hoping to get this into 1.x (this PR is off of the webpack-1 branch), which I'm assuming has to support Node <4. If that's out of the question, I suppose I can run off of my fork until I eventually get onto webpack 2.

Ah, good call... You should definitely base this from master.

Changed base to master.

Changed to template strings in 1c9a2ff. Is the code style okay? I figured real newlines in the code were better than \n, but if I make the indentation match the surrounding code it'll appear with all those extra tabs in the built file itself.

Match the current style for now. We have a stronger solution (webpack-defaults) in the pipeline that makes it easier to handle.

gauravtiwari · 2017-03-26T18:54:30Z

Hello folks, Any plans for merging this?

bebraw · 2017-03-27T06:42:22Z

We probably want final decision from Tobias before moving forward with this.

bebraw · 2017-03-27T09:42:02Z

I had a quick discussion with Tobias. Main points:

ETWP is slow so even with HMR, it's not a good solution for development.
Instead, we should recommend development specific setup (['style-loader', 'css-loader']) (faster) and document that.

Based on this the only way I can see this type of functionality going in is through a plugin of a plugin (html-webpack-plugin style). If it's possible to expose enough hooks, then you could implement extract-text-webpack-hmr-plugin or so without growing the core apart from the plugin interface.

msuperina · 2017-03-27T14:36:53Z

I wish I had time to look into it properly. In my opinion dev configuration should be as close as possible to production configuration. But as I said I can only blame myself for not bringing a proper solution.

…

On Mon, Mar 27, 2017 at 10:42 AM, Juho Vepsäläinen ***@***.*** > wrote: I had a quick discussion with Tobias. Main points: - ETWP is slow so even with HMR, it's not a good solution for development. - Instead, we should recommend development specific setup (['style-loader', 'css-loader']) (faster) and document that. Based on this the only way I can see this type of functionality going in is through a plugin of a plugin (*html-webpack-plugin* style). If it's possible to expose enough hooks, then you could implement *extract-text-webpack-hmr-plugin* or so without growing the core apart from the plugin interface. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#457 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARdIg_SkNQ0MLlC0xym5Nd1hJ5U_ot-gks5rp4RrgaJpZM4MYXeL> .

cletusw · 2017-03-27T15:49:37Z

@bebraw

ETWP is slow so even with HMR, it's not a good solution for development.

I fail to see how this is an argument against adding the option for HMR. I'm totally fine if the public recommendation is to avoid it and use a separate dev setup. I'm even fine if you have to pass ETWP an hmr flag. But not having the option because it may be slow? I think we can take it from the large number of comments asking for this feature that users want it, even if it may be slower. Also, at many companies, the developer time spent managing a large, complex split configuration far outweighs any slight decrease in speed using ETWP in dev.

cletusw · 2017-03-27T15:56:00Z

For anyone else who wants this feature, feel free to use my fork (npm install cletusw/extract-text-webpack-plugin#hmr or npm install cletusw/extract-text-webpack-plugin#hmr-webpack-1 if using webpack-1) in the meantime.

bebraw · 2017-03-27T19:22:38Z

@cletusw It's not my call to make. Tobias made it clear to me HMR does not belong here.

faceyspacey · 2017-04-05T01:14:31Z

@bebraw here's something that might change the equation:

Achieving the holy grail of Sever Side Rendering and Split Css Chunks.

React Loadable is on course to serve up just the chunks (js + css) your current request needs (I'm working on this feature). However, this can't be a production-only thing, where you only finally see that your server-side rendered code splitting is working during production. So you need to be able to serve up css chunks and you need HMR to continue to work. This is actually 2 issues, and I've discussed elsewhere how to get the ability to have more than one extracted text chunk. So if we can merge such a PR in, you need to be able to have access to those chunks AND HMR at the same time during development.

So @cletusw already built support for this. What's stopping merging his PR as an option. Not having it as an option is a major mistake. Perhaps @sokra isn't privy to the latest developments in server-side rendered code splitting. It seems to me an important direction that React + Webpack must finally go. As is, you can split chunks, but without significant work to incorporate chunks synchronously, a second request to get that chunk is needed, which also means any HTML it generates is not embedded in the initial page, which is bad for SEO. Contrary to what we might hope, code splitting isn't a solved problem (not outside Next.js at least). There is NO general and popular solution to embed required chunks (both JS + CSS) in the initial request for synchronous use client-side so React checksums match. There in fact is a lot of issues surrounding making this all work. I'm working on precisely this for React Loadable and am almost done. I have a few roundabout ways to make this all work that would be more seamless if ETWP extracted to individual chunks and if it supported extraction plus simultaneous HMR via the style-loader.

The future of apps is code splitting everywhere, but that can't happen without server-side rendering addressed or if it's only a testable reality in production.

faceyspacey · 2017-04-05T05:58:44Z

@cletusw I started using your fork and it seems to almost be working. On changes to CSS files, I'm seeing hot-update.js files like this added to the head of the page:

webpackHotUpdate(1,{

/***/ 161:
/***/ (function(module, exports, __webpack_require__) {

if (true) { __webpack_require__(92); }
// removed by extract-text-webpack-plugin
module.exports = {"title":"App__title--2FM-W"};
if (true) {
	module.hot.accept();
	if (module.hot.data) {
		__webpack_require__(92)('a4266d22532e157a0f3e','/static/','styles.css');
	}
}

/***/ })

})
//# sourceMappingURL=1.1f2fdd619a534186e86f.hot-update.js.map

And based on examination of the CSS HMR aspect of your code:

https://github.com/cletusw/extract-text-webpack-plugin/blob/360c155567b5e5f61ee0ecdab6d46c01a277b8c4/hotModuleReplacement.js

it's now supposed to look for the previous css file to replace. But how are those stylesheets supposed to initially get embedded in the page??

Here's my usage of the plugin in my webpack config:

{
        test: /\.css$/,
        use: ExtractTextPlugin.extract({
          fallback: "style-loader",
          use: "css-loader?modules&localIdentName=[name]__[local]--[hash:base64:5]"
        })
      },
...
 new ExtractTextPlugin({
      filename: 'styles.css',
      allChunks: true
    }),
new webpack.optimize.CommonsChunkPlugin({
      names: ['bootstrap'], //there is no bootstrap entry, so this purely contains webpack bootstrap code
      filename: '[name].[chunkhash].js',
      minChunks: Infinity,
    }),

UPDATE: I set allChunks: false and it filename: [name].[contenthash].css and HMR works on dynamic chunks lol, but not the main entry point. In addition, before HMR is even attempted, there is no CSS of the main entry point in the head on firs tload. Only if you have dynamic chunks will their css appear in the head.

It would be nice to actually make this work with individual css files generated for each chunk, as that is another feature I'm working on getting into this package or a fork. Perhaps that's more natural with how HMR is supposed to work anyway.

faceyspacey · 2017-04-05T08:45:51Z

@cletusw also, the extract styles file is no longer registered in the stats, e.g: stats.chunks[0].files.inculdes('styles.css') === false. It's also not in stats.assetsByChunkName.main, etc. This is key since most apps use the stats to discover such assets.

cletusw · 2017-04-13T21:48:14Z

@faceyspacey You need to include the CSS files manually in whatever .html file loads your .js. That's the same regardless of HMR.

As for the stats, I might not be able to get around to that for a while, but feel free to PR my fork!

faceyspacey · 2017-04-13T22:01:01Z

@cletusw Thanks so much for the response. Including the files manually is basically what I resolved to. That actually happens to work out perfectly in my unique scenario since I changed extract-textwebpack-plugin to produce multiple css files for dynamic chunks.

A for fixing my issues with HMR, I actually was able to make your implementation work eventually. I then tried to make it work with my setup to produce multiple css files. For some reason, I had the following issue: HMR appends ?123455, but the corresponding files aren't updated on the server. This is funny because if I use the [contenthash] in the file names, they are generated. What I did was then change the HMR code to append/replace file names like this: main.12345.css, 0.12345.css, etc, which is unfortunate since it essentially hard-codes the requirement that your format the names of your css files that way. Do you know of any reason why file names without hashes might not get updated, whereas if they do have hashes, new files are in fact created for each change?

I know I'm introducing another aspect (creating multiple css files for dynamic chunks), but I'd love if you could take a look at what I've done. I built this to work with React Loadable by the way so all the css and js of dynamic chunks can be sent from the server for synchronously requiring on the client in one render. I have a real nice setup going right now--it just would be ideal to get the code back into this package.

I'll send you my fork in a little bit. Basically the goal would be to make what I built work with filenames just based on [name] without the [contenthash], and of course to make handling of dynamic chunks an option, whereas now my fork is basically a package i intended on naming extract-css-chunk with very few configuration options, since I haven't received much response from the people behind extract-text-webpack-plugin.

faceyspacey · 2017-04-15T09:22:32Z

@cletusw here's my package that provides css files per chunk and working HMR:

https://github.com/faceyspacey/extract-css-chunk

If you have some time, take a look at it, and then maybe we can discuss a version of these changes that can be merged into this package.

cletusw · 2017-04-15T15:37:59Z

@faceyspacey That looks awesome!

bebraw · 2017-04-15T18:54:15Z

Just to chime in, likely the best way to proceed would be to figure out how to expose an API you can hook into. After that it would need ETWP+ to work. That feels like the best way based on Tobias' decision.

faceyspacey · 2017-04-15T19:56:24Z

@bebraw ok, that shouldn't be too hard. But first we have these todos:

figure out how to make files update with HMR when the file name is the same, i.e. doesn't use a content hash. @cletusw did you have any ideas on what could be preventing that?
provide an option (perhaps fallback: false) which toggles on the extracting of dynamic chunks into multiple css files. @bebraw what do you think about incorporating that as an option? All I pretty much did was comment out the following code to make that happen:

faceyspacey/extract-css-chunk@0739c47#diff-168726dbe96b3ce427e7fedce31bb0bcR313

That basically avoids merging all extracted css into one css file. I'm not fully sure I captured all possible cases by making that sweeping change.

code4cake · 2017-04-17T08:12:09Z

Hey guys, sorry for jumping in on the conversation, but doest HMR works with this plugin and if so where could I go and find a working implementation I could use as a reference or what do I need to change to make it work. Thanks.

faceyspacey · 2017-04-18T02:19:04Z

@cletusw up above provides a fork to use his HMR implementation:

#457 (comment)

It works. Give it a try and report back if there are any problems. ...FYI, I took his implementation and made HMR work as part of a new package extract-css-chunk (linked above), which creates individual css files for all your chunks (for use with code splitting).

faceyspacey · 2017-04-18T06:52:43Z

@cletusw ...I was thinking back to what you said regarding:

You need to include the CSS files manually in whatever .html file loads your .js. That's the same regardless of HMR.

That didn't affect what I was doing since extract-css-chunk's specific goal is getting those individual CSS files into the page, however that is not in fact how style-loader typically works. It typically appends the <style> elements for you, and then keeps them up to date. That's the expected behavior.

I made the following edit to your code to make that work

resultSource += `
var moduleId = "${text[0][0]}";
var css = "${text[0][1].split("\n").join("")}";			
var addStyles = require("${require.resolve("../style-loader/addStyles.js")}");		
addStyles([[moduleId, css]], "");

// REMOVE THE FOLLOWING:
//if (module.hot) {
//	module.hot.accept();
//	if (module.hot.data) {
//		require('${require.resolve("./hotModuleReplacement.js")}')('%%extracted-hash%%','${publicPath}','%%extracted-file%%');
//	}
//}`

So notice how style-loader/addStyles.js is used instead. Currently I have to manually add this file to my bootstrap or vendor entry point like this:

entry: {
   vendor: ['style-loader/addStyles.js']
   main: [...]
}

any ideas how to automatically add this to the webpack bootstrap chunk?

But it works like a charm, and you don't have to worry about adding the css file (possibly with a dynamic hash, which you need to get from stats) to the page. Perhaps this is less relevant in how you initially envisioned it where you have just one main.css file. For me having multiple chunks, it was a bit scarier. In addition, it's something I have to bring back to extract-css-chunk given that if you load chunks asynchronously after the first page load, they won't have the extracted css chunk file giving it its css.

cletusw · 2017-04-18T19:43:15Z

@faceyspacey Ummm, why do you need extract-text-webpack-plugin then? style-loader already does exactly what you want by itself. The only reason to use extract-text-webpack-plugin is when you want a separate CSS file that you can load from your HTML. If you're loading it from JS, then you don't need extract-text-webpack-plugin.

Also, this thread is getting significantly off topic. We can have further conversation about my fork or yours in an issue in their respective repos.

cletusw · 2017-04-18T19:55:39Z

@bebraw Thanks for all your responses, but at this time I'm not interested in adding additional complexity (both code-wise and for the user) to this by having it be a separate plugin-to-a-plugin, especially when the lack of HMR is explicitly listed as a shortcoming of the existing implementation. From the README:

I'll continue using my fork in the hope that this PR will someday be merged. In the meantime, anyone else is free to take this work and attempt to implement it as a separate plugin to this plugin.

faceyspacey · 2017-04-18T23:02:16Z

@cletusw good point. The goal has been to have both extract-text-webpack-plugin + style-loader, but if you're using extract-text-webpack-plugin, you're obviously using it to embed the CSS manually. So yea, if you only have one CSS file, style-loader isn't needed.

However, having both solves a key problem when it comes to multiple css files generated from dynamic chunks: the fact that you're only embedding the needed css chunks for the initial request, whereas if the client later loads different split chunks, webpack doesn't know how to load both the js and css chunk files. So to handle that what I've done is create 2 js chunks:

0.1234.js
0.1234.no_css.js

And then what I have is React Loadable embedding the js chunk without the css in the initial HTML returned from the server. And then as more chunks are asynchronously loaded, the chunks with the css (provided via style-loader) are provided!

This allows for the smallest chunk sizes embedded in the initial request, i.e. no duplicate css.

Anyway, that's how I stumbled upon using style-loader directly. But, it's not needed in the initial single css file setup you envisioned the HMR for.

mieszko4 · 2017-04-19T09:52:40Z

@cletusw Using your fork with combination of https://github.com/halt-hammerzeit/universal-webpack/ for some reason generates an empty styles: {} object in webpack-chunks.json - this file should contain styles: {} with filenames of generated .css.
It happens to me when I build my client files.

michael-ciniawsky · 2017-04-25T15:14:39Z

I will close this, please release this PR as a separate plugin, the sole purpose of ETWP is to extract the CSS chunks from the bundle and emit a separate CSS file. For HMR in development enviroments style-loader is the recommended solution. Thx

mieszko4 · 2017-04-25T15:43:22Z

@michael-ciniawsky I could not set style-loader with source maps as I did with ETWP - that's why I would like to see ETWP to implement HMR.

michael-ciniawsky · 2017-04-25T15:58:50Z

@mieszko4 Please open an issue in regard to what currently doesn't work, when using sourceMap + style-loader @style-loader instead 😛 . We appreciated any feedback you can provide us to fix regressions there, but HMR isn't simply the purpose of ETWP. ETWP should mainly be used for production builds to gather and extract the CSS chunks

`style-loader`

webpack-contrib/style-loader#153 (Fix/Set sourceRoot)
webpack-contrib/style-loader#219 (Inline SourceMap)

faceyspacey · 2017-04-28T05:09:06Z

UPDATE: Here's the latest from extract-css-chunks-webpack-plugin

HMR + Multiple CSS Chunks
USE IT!

To immediately see it in action, try out the boilerplate:

https://github.com/faceyspacey/flush-chunks-boilerplate

Also note, it's part of a larger initiative revolving around React Loadable and its companion package 💩 Webpack Flush Chunks:

https://github.com/faceyspacey/webpack-flush-chunks
https://github.com/thejameskyle/react-loadable

I'm open to merging code back into ETWP, but given how complex this code is (and it is), it really needs leadership from the original maintainers. Kickstarting the plugin of a plugin thing is something I'm willing to help anyone else who gets serious about it and wants to lead it, but I likely won't end up spearheading it, as it doesn't make sense to work on a PR that might not get merged. I think given @cletusw 's efforts which were not accepted, some effort from core EWTP maintainers in this direction makes the most sense as the next step (given we both have done a lot of work and demonstrated the base capabilities). I'm ready and willing should that time come.

For now the best thing likely is to start using the extract-css-chunks package and make sure it's solid. Only then after a bunch of people use it we can think about merging back into ETWP. That's probably most natural and logical anyway.

cletusw commented Mar 9, 2017

View reviewed changes

Jessidhia reviewed Mar 10, 2017

View reviewed changes

cletusw changed the base branch from webpack-1 to master March 10, 2017 05:53

Support hot module replacement

360c155

cletusw force-pushed the hmr branch from 1c9a2ff to 360c155 Compare March 10, 2017 06:12

gauravtiwari mentioned this pull request Mar 26, 2017

HMR for CSS rails/webpacker#188

Closed

mieszko4 mentioned this pull request Apr 18, 2017

Reloading extracted css with hot module replacement #30

Closed

michael-ciniawsky changed the title ~~Support hot module replacement~~ feat: support hot module replacement (HMR) Apr 22, 2017

michael-ciniawsky added semver: Minor pr_action: Blocked type: Feature labels Apr 22, 2017

michael-ciniawsky closed this Apr 25, 2017

michael-ciniawsky removed semver: Minor pr_action: Blocked type: Feature labels Apr 25, 2017

feat: support hot module replacement (HMR) #457

feat: support hot module replacement (HMR) #457

Conversation

cletusw commented Mar 9, 2017

jsf-clabot commented Mar 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cletusw Apr 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

faceyspacey Apr 29, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cletusw commented Mar 9, 2017

codecov bot commented Mar 9, 2017 • edited Loading

Codecov Report

bebraw commented Mar 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Jessidhia Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cletusw Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gauravtiwari commented Mar 26, 2017

bebraw commented Mar 27, 2017

bebraw commented Mar 27, 2017 • edited Loading

msuperina commented Mar 27, 2017 via email

cletusw commented Mar 27, 2017

cletusw commented Mar 27, 2017 • edited Loading

bebraw commented Mar 27, 2017

faceyspacey commented Apr 5, 2017 • edited Loading

faceyspacey commented Apr 5, 2017 • edited Loading

faceyspacey commented Apr 5, 2017

cletusw commented Apr 13, 2017

faceyspacey commented Apr 13, 2017 • edited Loading

faceyspacey commented Apr 15, 2017

cletusw commented Apr 15, 2017

bebraw commented Apr 15, 2017

faceyspacey commented Apr 15, 2017 • edited Loading

code4cake commented Apr 17, 2017

faceyspacey commented Apr 18, 2017 • edited Loading

faceyspacey commented Apr 18, 2017 • edited Loading

cletusw commented Apr 18, 2017 • edited Loading

cletusw commented Apr 18, 2017

faceyspacey commented Apr 18, 2017 • edited Loading

mieszko4 commented Apr 19, 2017

michael-ciniawsky commented Apr 25, 2017

mieszko4 commented Apr 25, 2017

michael-ciniawsky commented Apr 25, 2017

style-loader

faceyspacey commented Apr 28, 2017 • edited Loading

jsf-clabot commented Mar 9, 2017 •

edited

Loading

cletusw Apr 28, 2017 •

edited

Loading

faceyspacey Apr 29, 2017 •

edited

Loading

codecov bot commented Mar 9, 2017 •

edited

Loading

Jessidhia Mar 10, 2017 •

edited

Loading

cletusw Mar 10, 2017 •

edited

Loading

bebraw commented Mar 27, 2017 •

edited

Loading

cletusw commented Mar 27, 2017 •

edited

Loading

faceyspacey commented Apr 5, 2017 •

edited

Loading

faceyspacey commented Apr 5, 2017 •

edited

Loading

faceyspacey commented Apr 13, 2017 •

edited

Loading

faceyspacey commented Apr 15, 2017 •

edited

Loading

faceyspacey commented Apr 18, 2017 •

edited

Loading

faceyspacey commented Apr 18, 2017 •

edited

Loading

cletusw commented Apr 18, 2017 •

edited

Loading

faceyspacey commented Apr 18, 2017 •

edited

Loading

`style-loader`

faceyspacey commented Apr 28, 2017 •

edited

Loading