ifdef-loader - npm Package Compare versions

Comparing version 2.3.0 to 2.3.1

package.json

 {
   "name": "ifdef-loader",
-  "version": "2.3.0",
+  "version": "2.3.1",
   "description": "",
@@ -5,0 +5,0 @@ "main": "ifdef-loader.js",

preprocessor.js

@@ -62,3 +62,3 @@ "use strict";
         return source;
-    var lines = source.split('\n');
+    var lines = source.split(/\r\n|\n|\r/);
     var ifBlocks = find_if_blocks(lines);
@@ -65,0 +65,0 @@ for (var _i = 0, ifBlocks_1 = ifBlocks; _i < ifBlocks_1.length; _i++) {

preprocessor.ts

@@ -59,3 +59,3 @@ import { OptionObject } from 'loader-utils';
 
-   const lines = source.split('\n');
+   const lines = source.split(/\r\n|\n|\r/);
 
@@ -62,0 +62,0 @@ const ifBlocks = find_if_blocks(lines);

README.md

@@ -100,2 +100,41 @@ # ifdef-loader
 
+## Code in comments
+
+Often times writing `#if` ... `#else` ... `#endif` results in code that is not syntactically valid
+or does not pass the LINT check. A possible workaround is to hide such code in comments
+and let `ifdef-loader` uncomment it if it's part of the block that has to be included in the output.
+
+Example:
+
+The following code is invalid because the linter sees a double declaration of the `a` variable.
+```
+// #if DEBUG
+let a=1;
+// #else
+let a=2;
+// #endif
+```
+
+Using code in comments:
+```
+// #if DEBUG
+let a=1;
+// #else
+// #code let a=2;
+// #endif
+```
+The code is now under comment so it's ignored by the linter; but it's uncommented
+by `ifdef-loader` if the else branch has to be included in the output (that is when `DEBUG==false`).
+
+The `// #code ` string prefix can be changed and has to be explictly specified
+in the options object:
+
+```
+const opts = {
+   // ...
+   "ifdef-uncomment-prefix": "// #code ",
+   // ...
+};
+```
+
 ## License
@@ -102,0 +141,0 @@

No alert changes

Improved metrics

Total package byte prevSize

29616

increased by3.48%

Number of lines in readme file

176

increased by28.47%

No dependency changes