Make this package implementation-agnostic #573

nex3 · 2018-05-25T18:33:51Z

Rather than always loading Node Sass, this now requires users to pass in
either Dart Sass or Node Sass as an option to the loader.

Closes #435

jsf-clabot · 2018-05-25T18:33:52Z

All committers have signed the CLA.

codecov · 2018-05-25T18:41:20Z

Codecov Report

Merging #573 into master will increase coverage by 0.26%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #573      +/-   ##
==========================================
+ Coverage   97.54%   97.81%   +0.26%     
==========================================
  Files           6        6              
  Lines         122      137      +15     
==========================================
+ Hits          119      134      +15     
  Misses          3        3

Impacted Files	Coverage Δ
lib/loader.js	`100% <100%> (ø)`	⬆️

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 714f5c6...41b0079. Read the comment docs.

alexander-akait

Thanks for PR! Good work!

alexander-akait · 2018-05-28T10:59:33Z

CHANGELOG.md

+        }]
+    }
+};
+```


Thanks for working docs, but please remove this, we can do this before release.

alexander-akait · 2018-05-28T11:00:21Z

README.md

+                {
+                  loader: "sass-loader", // compiles Sass to CSS
+                  // require("node-sass") instead to use Node Sass
+                  options: {sass: require("sass")}


Should not be option. sass-loader should resolve node-sass, then try to resolve dart-sass, if not found nothing - throw error

Are you sure? Not allowing users to explicitly control this will mean that if they (or one of their dependencies if they're using flat dependencies) requires Node Sass for some unrelated reason, they're forced to use Node Sass. This may even result in them unexpectedly switching to Node Sass down the line.

It seems like several users would prefer making this configuration explicit.

@nex3 Hm, yes you are right it can lead to problems, let's rename sass to implementation and load node-sass by default. It is allow to upgrade loader without break build and avoid unnecessary major.

Done. It's worth noting though that the name implementation, in addition to being more of a pain to type, means that users can't just write

const sass = require("sass"); // ... options: { sass } // ...

alexander-akait · 2018-05-28T11:01:08Z

README.md

+                loader: "sass-loader",
+                options: {
+                    sass: require("sass"),
+                    fiber: Fiber


Move this to internal behavior (no new options), please provide benchmark for this

I'm not sure what you mean by "move this to internal behavior". Do you want sass-loader to depend on fibers itself? Be aware that fibers requires native compilation, and may be difficult to install on some systems.

I'm not sure what kind of benchmarks you're looking for, but as the maintainer of Dart Sass, I can assure you that a 2x speed hit is what we measure pretty consistently when using the asynchronous code path.

@nex3 okey, let's leave this as is

alexander-akait · 2018-05-28T11:03:05Z

test/index.test.js

@@ -6,6 +6,7 @@ const path = require("path");
 const webpack = require("webpack");
 const fs = require("fs");
 const merge = require("webpack-merge");
+const sass = require("node-sass");


Tests should be running on node-sass an dart-sass together, we need change test script:

Install node-sass and run tests

Install dart-sass and run tests.

I'm not sure how to do that gracefully, especially if the implementation isn't supplied as an option.

@nex3 skip tests where dart-sass doesn't have options/features/etc and add comments about this. Why? After release all people starting upgrade and we will get a lot of issues like "It is woks on x.x.x version, but after upgrade to x.x.x it is doesn't works. [A lot of angry words]" (a lot of people don't read changelog and release pages). We should prepare to this.

Okay, but at a higher level I'm not sure how to run these tests with both versions of Sass or how to switch between those versions.

Just add additional look here https://github.com/webpack-contrib/sass-loader/blob/master/test/index.test.js#L35 with node-sass and sass values and we need some modify tests to allow using difference implementation

I'm still not sure I understand. Can you give me an example of what a test you're envisioning would look like?

Like this (pseudo code):

implementations.forEach(implementation => { syntaxStyles.forEach(ext => { loaderOptions.implementation = implementation // tests }); })

Also add implementations.forEach here https://github.com/webpack-contrib/sass-loader/blob/master/test/index.test.js#L112

alexander-akait · 2018-05-28T11:04:03Z

package.json

@@ -1,6 +1,6 @@
 {
  "name": "sass-loader",
-  "version": "7.0.1",
+  "version": "8.0.0",


Don't change this.

alexander-akait · 2018-05-28T11:04:47Z

lib/loader.js

+            throw new Error("Dart Sass version " + version + " is incompatible with ^1.3.0.");
+        }
+    } else if (implementation === "node-sass") {
+        if (major < 4 || major > 4) {


Can you provide information why node-sass > 4 is not compatibility?

Node Sass 5 hasn't been released yet. According to semver, it may introduce arbitrary breaking changes, so it's not safe to eagerly declare compatibility with it.

alexander-akait · 2018-05-28T11:05:07Z

lib/loader.js

+
+    const implementation = parsed[1];
+    const version = parsed[2];
+    const components = /^(\d+)\.(\d+)/.exec(version);


Use semver package for this

nex3

These changes seem to have made branch coverage on loader.js fall below the threshold, but I'm not sure why since I only changed the conditions without changing any branches.

nex3 · 2018-05-28T19:36:10Z

CHANGELOG.md

+        }]
+    }
+};
+```


nex3 · 2018-05-28T19:36:44Z

README.md

+                {
+                  loader: "sass-loader", // compiles Sass to CSS
+                  // require("node-sass") instead to use Node Sass
+                  options: {sass: require("sass")}


Are you sure? Not allowing users to explicitly control this will mean that if they (or one of their dependencies if they're using flat dependencies) requires Node Sass for some unrelated reason, they're forced to use Node Sass. This may even result in them unexpectedly switching to Node Sass down the line.

It seems like several users would prefer making this configuration explicit.

nex3 · 2018-05-28T19:41:44Z

README.md

+                loader: "sass-loader",
+                options: {
+                    sass: require("sass"),
+                    fiber: Fiber


I'm not sure what you mean by "move this to internal behavior". Do you want sass-loader to depend on fibers itself? Be aware that fibers requires native compilation, and may be difficult to install on some systems.

I'm not sure what kind of benchmarks you're looking for, but as the maintainer of Dart Sass, I can assure you that a 2x speed hit is what we measure pretty consistently when using the asynchronous code path.

nex3 · 2018-05-28T19:48:50Z

lib/loader.js

+
+    const implementation = parsed[1];
+    const version = parsed[2];
+    const components = /^(\d+)\.(\d+)/.exec(version);


nex3 · 2018-05-28T19:49:41Z

lib/loader.js

+            throw new Error("Dart Sass version " + version + " is incompatible with ^1.3.0.");
+        }
+    } else if (implementation === "node-sass") {
+        if (major < 4 || major > 4) {


Node Sass 5 hasn't been released yet. According to semver, it may introduce arbitrary breaking changes, so it's not safe to eagerly declare compatibility with it.

nex3 · 2018-05-28T19:51:13Z

package.json

@@ -1,6 +1,6 @@
 {
  "name": "sass-loader",
-  "version": "7.0.1",
+  "version": "8.0.0",


nex3 · 2018-05-28T19:52:32Z

test/index.test.js

@@ -6,6 +6,7 @@ const path = require("path");
 const webpack = require("webpack");
 const fs = require("fs");
 const merge = require("webpack-merge");
+const sass = require("node-sass");


I'm not sure how to do that gracefully, especially if the implementation isn't supplied as an option.

alexander-akait · 2018-05-28T20:10:07Z

lib/loader.js

@@ -62,6 +41,16 @@ function sassLoader(content) {
        addNormalizedDependency
    ));

+    if (asyncSassJobQueue === null) {
+        if (!options.sass) {


Better rename to implementation, sass is very misleading

And should be node-sass by default (comment above).

alexander-akait · 2018-05-28T20:15:58Z

lib/loader.js

+ * @param {string} info
+ */
+function validateSassVersion(info) {
+    const parsed = /^([^\t]+)\t([^\t]+)/.exec(info);


Don't use regex here, please use semver for parsing major and minor

@nex3 looks we still use /^([^\t]+)\t([^\t]+)/.exec(info), better use semver.major, semver.minor and semver.patch functions

This last regex isn't parsing the semver itself, it's parsing the implementation name and version number from the info string. I could also use info.split("\t") if you want to avoid any regexes.

@nex3 maybe we can do this without regex?

alexander-akait · 2018-05-29T02:36:47Z

README.md

+                {
+                  loader: "sass-loader", // compiles Sass to CSS
+                  // require("node-sass") instead to use Node Sass
+                  options: {implementation: require("sass")}


Let's left default example as is and improve section about dart-sass
Like this:

<h2 align="center">Examples</h2> ### `node-sass` default // Description and example ### `dart-sass` // Description and example

I can do that if you want, but from the perspective of the Sass organization, I'd really like to present Dart Sass and Node Sass as equal options. Making Node Sass the default for backwards-compatibility makes sense, but in terms of end-user messaging I think it makes more sense to frame it as something each user should explicitly choose.

Also, from the perspective of end users, I think most people will find a lot of value in starting with Dart Sass because it's easy to install and moving to LibSass if and when they need a performance boost. Presenting the default documented workflow as LibSass first means you'll have some percentage of users whose first interaction with sass-loader is installation woes caused by native compilation.

@nex3 please do this, we switch on dart sass in next major release. We should try dart sass in wild before release major.

alexander-akait · 2018-05-29T02:41:23Z

Good work! Thanks!

alexander-akait · 2018-06-01T12:42:29Z

test/index.test.js

@@ -6,6 +6,7 @@ const path = require("path");
 const webpack = require("webpack");
 const fs = require("fs");
 const merge = require("webpack-merge");
+const sass = require("node-sass");


Like this (pseudo code):

implementations.forEach(implementation => { syntaxStyles.forEach(ext => { loaderOptions.implementation = implementation // tests }); })

alexander-akait · 2018-06-01T12:43:42Z

test/index.test.js

@@ -6,6 +6,7 @@ const path = require("path");
 const webpack = require("webpack");
 const fs = require("fs");
 const merge = require("webpack-merge");
+const sass = require("node-sass");


Also add implementations.forEach here https://github.com/webpack-contrib/sass-loader/blob/master/test/index.test.js#L112

nex3

This seems to have the coverage failing by a small margin again, and I'm not sure what to do about that.

nex3 · 2018-06-02T00:21:04Z

README.md

+                {
+                  loader: "sass-loader", // compiles Sass to CSS
+                  // require("node-sass") instead to use Node Sass
+                  options: {implementation: require("sass")}


nex3 · 2018-06-02T00:21:11Z

lib/loader.js

+ * @param {string} info
+ */
+function validateSassVersion(info) {
+    const parsed = /^([^\t]+)\t([^\t]+)/.exec(info);


nex3 · 2018-06-02T00:22:19Z

test/index.test.js

@@ -6,6 +6,7 @@ const path = require("path");
 const webpack = require("webpack");
 const fs = require("fs");
 const merge = require("webpack-merge");
+const sass = require("node-sass");


alexander-akait · 2018-06-04T09:37:55Z

@nex3 don't look on coverage, also please rebase 👍

Rather than always loading Node Sass, this now requires users to pass in either Dart Sass or Node Sass as an option to the loader. Closes webpack-contrib#435

Importing stylesheets without extensions is non-standard behavior that's not supported in Dart Sass (see sass/libsass#2672).

nex3 · 2018-06-04T17:02:21Z

Done!

nex3 · 2018-06-16T00:31:59Z

@evilebottnawi Is there anything left to be done here?

alexander-akait · 2018-06-21T18:38:13Z

@nex3 sorry for delay, review tomorrow, a lot of work, thanks for work!

nex3 · 2018-06-28T18:41:31Z

Friendly ping!

alexander-akait · 2018-06-29T09:45:35Z

test/sass/import-css.sass

-// 2. It does not matter whether the CSS-file exists or not, the file is just linked
-@import ./does/not/exist.css
-// 3. When the .css extension is missing, the file is included just like scss
-@import ~css/some-css-module


Why some tests will be removed?

CSS imports are not currently supported by Dart Sass. CSS imports with the .css suffix are also slated for removal from LibSass.

@nex3 can we left css tests only for node-sass, we remove this after upgrade node-sass to 5.

I don't know how, since all these test files are shared between the two implementations.

@nex3 need investigate, will be great if you do this, otherwise i can try this too

I definitely don't know how to do it without a huge refactor of how tests are run.

@evilebottnawi - do you have any ETA when you might be able to look at this? :) Or, is it possible to move forward without this, as the features being tested are soon to deprecate anyway?

@TroyAlford need @jhnns review

alexander-akait · 2018-06-29T09:45:56Z

BTW Great work! Thanks!

Gnuk · 2018-07-08T07:51:02Z

README.md

@@ -24,11 +24,17 @@ Looking for the webpack 1 loader? Check out the [archive/webpack-1 branch](https
 <h2 align="center">Install</h2>

 ```bash
-npm install sass-loader node-sass webpack --save-dev
+npm install sass-loader sass webpack --save-dev


Why there is dart sass installation if node-sass is the default implementation?

"sass-loader" // compiles Sass to CSS, using Node Sass by default later in an example in this file.

Oops, I missed this. Changed back to node-sass.

jhnns

Thank you, the PR looks pretty good overall 🎉 👍

Besides my comment to fiber and the threadpool, I have another question: Why did you rename test/node_modules/module to test/node_modules/module.scss? The missing file extension was on purpose.

Anyway, I'm pretty confident that we can merge this soon. Thanks again for your hard work 👍

jhnns · 2018-07-11T14:39:44Z

README.md

+callbacks. To avoid this overhead, you can use the
+[`fibers`](https://www.npmjs.com/package/fibers) package to call asynchronous
+importers from the synchronous code path. To enable this, pass the `Fiber` class
+to the `fiber` option:


Since webpack uses the asynchronous compilation, can we automate that process? So that we just require("fiber") and apply the option automatically from normalizeOptions? I guess that every dart-sass user would want to have that speedup. If require("fiber") fails, we could instruct the user to install fiber and point a link to the dart-sass README.

In this README, I'd just mention something like "be sure to have fibers installed in your project, see dart-sass README" (with link).

What do you think?

We'd need to add fibers as dev dependency then.

Fiber is a native package, so including this by default would defeat the value of this change - not having C++ code in dependencies, make SASS as easy to use as Less or Stylus.

The caveats of native packages was one of the reasons to not include SASS by default into create-react-app: facebook/create-react-app#78 (comment)

The current documentation seems fine. When users would ask "compilation of my SASS is too slow, how can I speed this up?", they will be able to find an answer. But making fibers strong recommendation or even mandatory would sound like "You should buy Ferrari when you simply need a car".

I agree with @just-boris; there's a lot of value in providing an easy pure-JS set-up experience, and then letting performance-conscious users focus on that when they need it.

Something to consider, probably after this PR lands, would be adding an option to run Dart Sass in synchronous mode, which is efficient without the use of fibers (at the cost of not supporting async importers or custom functions).

Fiber is a native package, so including this by default would defeat the value of this change - not having C++ code in dependencies, make SASS as easy to use as Less or Stylus.

Good catch 👍 I totally agree.

Something to consider, probably after this PR lands, would be adding an option to run Dart Sass in synchronous mode, which is efficient without the use of fibers (at the cost of not supporting async importers or custom functions).

Yes, I'm thinking about moving away from async importers. This would be a good fit.

jhnns · 2018-07-11T15:03:59Z

lib/loader.js

+        const implementation = options.implementation || require("node-sass");
+
+        validateSassVersion(implementation.info);
+        asyncSassJobQueue = async.queue(implementation.render, threadPoolSize - 1);


The async job queue mitigates a problem of node-sass/libsass where the threadpool gets exhausted (see sass/node-sass#857 (comment)). Do you know if dart-sass suffers from the same problem? (I don't think so, unless you ask for a thread from libuv like node-sass does)

If not, we could get rid of the queue for dart-sass.

I don't believe Dart Sass suffers from that problem, but I wanted to keep the code path as similar between the two implementations as possible.

Seems reasonable, but I suspect the queue to be one of the performance bottlenecks as discussed in #296. However, that's not a blocker for this PR.

jhnns · 2018-07-11T15:10:17Z

lib/loader.js

+        throw new Error("Unknown implementation \"" + implementation + "\".");
+    }
+}
+


jhnns · 2018-07-11T15:12:43Z

test/index.test.js

+                });
+                describe("prepending data", () => {
+                    it("should extend the data-option if present", () => execTest("prepending-data", {
+                        data: "$prepended-data: hotpink" + (ext == "sass" ? "\n" : ";")


Nice catch 👍

jhnns · 2018-07-11T15:14:52Z

test/index.test.js

-                                // @see https://github.com/webpack-contrib/sass-loader/issues/368#issuecomment-278330164
-                                { loader: pathToSassLoader, options: {} }
-                            ]
-                        }]


Thanks for deduping that

jhnns · 2018-07-11T15:16:11Z

test/index.test.js

+            describe("source maps", () => {
+                function buildWithSourceMaps() {
+                    return new Promise((resolve, reject) => {
+                        webpack({


Why can't you re-use runWebpack here?

This uses different values for module.rules, which webpack-merge can't merge in (it would just try to add rules to the list rather than replacing it entirely).

jhnns · 2018-07-11T15:17:20Z

test/index.test.js

+                            sourceMap.should.have.property("sourceRoot", fakeCwd);
+                            // This number needs to be updated if imports.scss or any dependency of that changes.
+                            // Node Sass includes a duplicate entry, Dart Sass does not.
+                            sourceMap.sources.should.have.length(implementation == nodeSass ? 12 : 11);


We can get rid of the duplicated dependency. Makes this test easier. Which dependency is duplicated?

jhnns · 2018-07-11T15:18:29Z

test/index.test.js

+                        } else {
+                            err.message.should.match(/Expected "{"./);
+                            err.message.should.match(/\(line 3, column 1\)/);
+                        }


In the long run it would probably be better to compare these errors with errors that have been snapshotted during createSpec, but that's ok for now I guess.

jhnns · 2018-07-11T15:19:05Z

test/index.test.js

+                    }, {
+                        implementation: merge(nodeSass, { info: "strange-sass\t1.0.0" })
+                    }, (err) => {
+                        err.message.should.match(/Unknown implementation "strange-sass"\./);


Thanks for adding tests here 👍

nex3

Why did you rename test/node_modules/module to test/node_modules/module.scss? The missing file extension was on purpose.

That's another situation where you were testing import behavior that's being deprecated in LibSass and isn't supported at all in Dart Sass. See sass/libsass#2672.

nex3 · 2018-07-11T21:45:58Z

README.md

+callbacks. To avoid this overhead, you can use the
+[`fibers`](https://www.npmjs.com/package/fibers) package to call asynchronous
+importers from the synchronous code path. To enable this, pass the `Fiber` class
+to the `fiber` option:


I agree with @just-boris; there's a lot of value in providing an easy pure-JS set-up experience, and then letting performance-conscious users focus on that when they need it.

Something to consider, probably after this PR lands, would be adding an option to run Dart Sass in synchronous mode, which is efficient without the use of fibers (at the cost of not supporting async importers or custom functions).

nex3 · 2018-07-11T21:46:31Z

lib/loader.js

+        const implementation = options.implementation || require("node-sass");
+
+        validateSassVersion(implementation.info);
+        asyncSassJobQueue = async.queue(implementation.render, threadPoolSize - 1);


I don't believe Dart Sass suffers from that problem, but I wanted to keep the code path as similar between the two implementations as possible.

nex3 · 2018-07-11T21:49:57Z

test/index.test.js

+            describe("source maps", () => {
+                function buildWithSourceMaps() {
+                    return new Promise((resolve, reject) => {
+                        webpack({


This uses different values for module.rules, which webpack-merge can't merge in (it would just try to add rules to the list rather than replacing it entirely).

TroyAlford · 2018-07-20T18:10:42Z

Just a gentle nudge: what's next, in terms of getting this PR merged and released?

alexander-akait · 2018-07-20T18:12:58Z

/cc @nex3 @jhnns

TroyAlford · 2018-07-31T16:52:52Z

Really not wanting to be a pest, but there are some downstream additional changes that this gates. :) Any chance of getting some further review / a potential merge soon?

co3k · 2018-08-01T05:43:10Z

node-sass depends on node-gyp, but vulnerability handling by node-gyp team is very slow so we really need to have options to use alternative sass implementations. Please consider to merge this pull request.

In preparation for #573 Imports without file extensions are deprecated in LibSass and even not supported in DartSass.

See webpack-contrib#573 (comment)

jhnns · 2018-08-01T15:55:23Z

I've re-added the CSS tests for the node-sass implementation. I've also removed the queue for DartSass.

jhnns · 2018-08-01T16:07:12Z

Shipped with v7.1.0 🚀
Thanks for your great work @nex3 👍

alexander-akait requested changes May 28, 2018

View reviewed changes

alexander-akait added type: Feature severity: 4 (inconvenient) priority: 4 (important) semver: Minor labels May 28, 2018

nex3 commented May 28, 2018

View reviewed changes

alexander-akait reviewed May 28, 2018

View reviewed changes

nex3 mentioned this pull request May 28, 2018

Help migrate Node Sass tools to be implementation-agnostic sass/dart-sass#267

Closed

7 tasks

alexander-akait reviewed May 29, 2018

View reviewed changes

alexander-akait requested changes Jun 1, 2018

View reviewed changes

nex3 commented Jun 2, 2018

View reviewed changes

nex3 added 2 commits June 4, 2018 11:45

Make this package implementation-agnostic

55e9b48

Rather than always loading Node Sass, this now requires users to pass in either Dart Sass or Node Sass as an option to the loader. Closes webpack-contrib#435

Give new modules file extensions

3d24089

Importing stylesheets without extensions is non-standard behavior that's not supported in Dart Sass (see sass/libsass#2672).

nex3 force-pushed the dart-sass branch from e976db2 to 3d24089 Compare June 4, 2018 16:50

xzyfer mentioned this pull request Jun 8, 2018

sass-loader performance #296

Closed

alexander-akait requested changes Jun 29, 2018

View reviewed changes

alexander-akait approved these changes Jul 6, 2018

View reviewed changes

nex3 mentioned this pull request Jul 6, 2018

how to use sass in webpack sass/sass#2534

Closed

Gnuk mentioned this pull request Jul 7, 2018

Dart Sass support as a stylesheet preprocessor option vuejs/vue-cli#1782

Closed

just-boris mentioned this pull request Jul 7, 2018

dart-sass? #435

Closed

Gnuk reviewed Jul 8, 2018

View reviewed changes

Install Node Sass in the example

05d20e6

jhnns self-requested a review July 11, 2018 09:36

jhnns mentioned this pull request Jul 11, 2018

feat(importer): add support for custom file extensions (options.extensions) #583

Closed

jhnns requested changes Jul 11, 2018

View reviewed changes

nex3 commented Jul 11, 2018

View reviewed changes

clydin mentioned this pull request Jul 31, 2018

Github security warning for hoek angular/angular-cli#11699

Closed

jhnns added a commit that referenced this pull request Aug 1, 2018

test: Refactor module import tests

83149e8

In preparation for #573 Imports without file extensions are deprecated in LibSass and even not supported in DartSass.

jhnns mentioned this pull request Aug 1, 2018

test: Refactor module import tests #599

Merged

jhnns added a commit that referenced this pull request Aug 1, 2018

test: Refactor module import tests (#599)

714f5c6

In preparation for #573 Imports without file extensions are deprecated in LibSass and even not supported in DartSass.

jhnns added 3 commits August 1, 2018 16:24

Re-add CSS tests for node-sass implementation

8f8081b

Merge branch 'master' into pr/origin/573

19d4ed2

Only use job queue for node-sass

41b0079

See webpack-contrib#573 (comment)

jhnns approved these changes Aug 1, 2018

View reviewed changes

jhnns merged commit bed9fb5 into webpack-contrib:master Aug 1, 2018

nex3 deleted the dart-sass branch August 1, 2018 19:59

Gnuk mentioned this pull request Aug 19, 2018

Feature Set, Vue CLI and some general question jhipster/jhipster-vuejs#1

Closed

fsubal mentioned this pull request Sep 12, 2018

Supporting option for dart-sass ? ( or drop node-sass as dependency ) fetch/node-sass-asset-functions#16

Open

bbugh mentioned this pull request Aug 9, 2019

Update node-sass troubleshooting information rails/webpacker#2206

Merged

snyk-bot mentioned this pull request Mar 28, 2020

[Snyk] Upgrade sass-loader from 7.1.0 to 8.0.2 lwojcik/sc2pte-panel-frontend#98

Closed

AprilArcus mentioned this pull request Mar 16, 2022

Update packagist for 3.4.3 twbs/bootstrap-sass#1228

Open

Make this package implementation-agnostic #573

Make this package implementation-agnostic #573

Conversation

nex3 commented May 25, 2018

jsf-clabot commented May 25, 2018 • edited

codecov bot commented May 25, 2018 • edited

Codecov Report

alexander-akait left a 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

alexander-akait May 28, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexander-akait May 28, 2018 • edited

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

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

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

nex3 left a 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

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

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexander-akait commented May 29, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nex3 left a 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

alexander-akait commented Jun 4, 2018

nex3 commented Jun 4, 2018

nex3 commented Jun 16, 2018

alexander-akait commented Jun 21, 2018

nex3 commented Jun 28, 2018

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexander-akait commented Jun 29, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsf-clabot commented May 25, 2018 •

edited

codecov bot commented May 25, 2018 •

edited

alexander-akait May 28, 2018 •

edited

alexander-akait May 28, 2018 •

edited

alexander-akait commented May 29, 2018 •

edited

just-boris Jul 11, 2018 •

edited