Trigger hard-source error after syntax error

[Huai-Kang]

• Step 1, trigger a js syntax error

  ERROR in ./static/shared/js/component/add-to-cart.js
  Module build failed: SyntaxError: Unexpected token, expected ; (13:15)
  
  11 |  */
  12 |
  > 13 | var injectTapE ventPlugin = require("react-tap-event-plugin");
   |                ^
  14 | injectTapEventPlugin();
  15 | var HeadIcon = Tool.getComponent('HeadIcon');
  16 | /**
  
  @ ./static/shared/js/plugin/quickShop.js 27:0-57
  @ ./static/stylewe/pc/js/home.js

• Then, trigger a hard-source error after I fixed js syntax error

  [hardsource:5ce021c9] Using 20 MB of disk space.
  (node:26025) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 51): TypeError: Cannot read property 'indexOf' of undefined
  (node:26025) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

• Restart npm scripts to compile app, then I got anthor error

  
  [hardsource:5ce021c9] Using 20 MB of disk space.
  [hardsource:5ce021c9] Tracking node dependencies with: package-lock.json, yarn.lock.
  [hardsource:5ce021c9] Reading from cache 5ce021c9...
  /Users/feel-joy/Code/stylewe/node_modules/loader-runner/lib/LoaderRunner.js:19
  var i = req.indexOf("?");
             ^

TypeError: Cannot read property 'indexOf' of undefined at splitQuery (/Users/Code/stylewe/node_modules/loader-runner/lib/LoaderRunner.js:19:13) at getContext (/Users/Code/stylewe/node_modules/loader-runner/lib/LoaderRunner.js:238:17) at new NormalModule (/Users/Code/stylewe/node_modules/webpack/lib/NormalModule.js:66:18) at Object.thaw (/Users/fCode/stylewe/node_modules/hard-source-webpack-plugin/lib/util/serial.js:199:12) at Object.thaw (/Users/Code/stylewe/node_modules/hard-source-webpack-plugin/lib/util/serial.js:216:25) at Compiler.pluginCompat.tap (/Users/Code/stylewe/node_modules/hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30) at Compiler.applyPluginsWaterfall (/Users/Code/stylewe/node_modules/tapable/lib/Tapable.js:92:24) at Object.exports.call (/Users/Code/stylewe/node_modules/hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38) at thaw (/Users/Code/stylewe/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:126:29) at fetch (/Users/Code/stylewe/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:173:16) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! StyleWe-JustFashionNow-PopJulia@4.0.0 start: ./toolbox/build.js "sw" "pc" npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the StyleWe-JustFashionNow-PopJulia@4.0.0 start script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

* Env
  * Node: 8.0.0
  * Npm: 5.0.0
  * Webpack: 3.0.0
  * Hard-source: 0.12.0

This two bug can be resovled by remove hard-source cache, but I have to rebuild app and cache, this will take a lot of time, can someone help me to resolve this problem ?

[filipecatraia]

Going out on a limb here, but is it possible that

var injectTapE ventPlugin = require("react-tap-event-plugin"); should be var injectTapEventPlugin = require("react-tap-event-plugin"); ?

Note the missing space. Is the task runner responsible for it, or did you actually miss that typo?

This issue feels unrelated to this plugin.

[dhulme]

I experience the same issue. I think @Feel-Joy is saying that when he makes a JS syntax error, it causes the cache to become corrupted. I've been getting the error occasionally, but I didn't make the connection with syntax errors until now.

[sanchitgera]

I'm able to reproduce this error without making any syntax errors. If I trigger a couple of webpack builds back to back (without making any changes to my code), the builds eventually start failing with this error. Any idea on what this could be?

[Ohar]

We went into this problem too. Now we are using workaround 😉 with clearing cache before build. Our package.json looks like that now

{
  "scripts": {
    "dev": "npm run clear && node .",
    "clear": "rimraf node_modules/.cache"
  }
}

[rkingon]

i am experiencing the same thing. otherwise a great addition to speed up our workflow.

@Ohar your solution of clearing defeats the purpose of the cache

[FengXianGuo]

i am experiencing the same thing. have any solutions?

[mvgijssel]

We have the same on our CI's (after a couple of builds) with hard-source-webpack-plugin 0.13.1.

/tmp/node_modules/loader-runner/lib/LoaderRunner.js:19
    var i = req.indexOf("?");
                ^

TypeError: Cannot read property 'indexOf' of undefined
    at splitQuery (/tmp/node_modules/loader-runner/lib/LoaderRunner.js:19:14)
    at getContext (/tmp/node_modules/loader-runner/lib/LoaderRunner.js:238:17)
    at new NormalModule (/tmp/node_modules/webpack/lib/NormalModule.js:69:18)
    at Object.thaw (/tmp/node_modules/hard-source-webpack-plugin/lib/util/serial.js:199:12)
    at Object.thaw (/tmp/node_modules/hard-source-webpack-plugin/lib/util/serial.js:216:25)
    at Compiler.pluginCompat.tap (/tmp/node_modules/hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30)
    at Compiler.applyPluginsWaterfall (/tmp/node_modules/tapable/lib/Tapable.js:92:24)
    at Object.exports.call (/tmp/node_modules/hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38)
    at thaw (/tmp/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:126:29)
    at fetch (/tmp/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:173:16)
    at NormalModuleFactory.normalModuleFactoryHooks.createModule.tap (/tmp/node_modules/hard-source-webpack-plugin/lib/TransformNormalModuleFactoryPlugin.js:213:28)
    at NormalModuleFactory.applyPluginsBailResult (/tmp/node_modules/tapable/lib/Tapable.js:129:27)
    at applyPluginsAsyncWaterfall (/tmp/node_modules/webpack/lib/NormalModuleFactory.js:75:31)
    at /tmp/node_modules/tapable/lib/Tapable.js:268:11
    at NormalModuleFactory.params.normalModuleFactory.plugin (/tmp/node_modules/webpack/lib/CompatibilityPlugin.js:52:5)
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/tmp/node_modules/tapable/lib/Tapable.js:272:13)
    at resolver (/tmp/node_modules/webpack/lib/NormalModuleFactory.js:69:10)
    at fromCache (/tmp/node_modules/hard-source-webpack-plugin/lib/TransformNormalModuleFactoryPlugin.js:178:22)
    at /tmp/node_modules/hard-source-webpack-plugin/lib/TransformNormalModuleFactoryPlugin.js:187:22
    at /tmp/node_modules/webpack/lib/NormalModuleFactory.js:59:4
    at applyPluginsAsyncWaterfall (/tmp/node_modules/webpack/lib/NormalModuleFactory.js:234:4)
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/tmp/node_modules/tapable/lib/Tapable.js:260:70)
    at NormalModuleFactory.create (/tmp/node_modules/webpack/lib/NormalModuleFactory.js:218:8)
    at _this.semaphore.acquire (/tmp/node_modules/webpack/lib/Compilation.js:237:13)
    at Semaphore.acquire (/tmp/node_modules/webpack/lib/util/Semaphore.js:16:4)
    at iteratorFactory (/tmp/node_modules/webpack/lib/Compilation.js:235:20)
    at /tmp/node_modules/async/dist/async.js:3083:16
    at eachOfArrayLike (/tmp/node_modules/async/dist/async.js:1003:9)
    at eachOf (/tmp/node_modules/async/dist/async.js:1051:5)
    at Object.eachLimit (/tmp/node_modules/async/dist/async.js:3145:5)

[akhoury]

@mvgijssel it happens occasionally to us too, just clear the cache before each CI build

rm -rf node_modules/.cache

it will slow down your build, but better than crashing it.

As for development env, I only clear the cache when this happens, which is like every 1/20 builds if I am taking a hard guess, which is fine to clear to cache 5% of the time till this is fixed

[mvgijssel]

Thanks @akhoury for the tip! Will try that, though like @rkingon mentioned that kinda defeats the purpose of the cache.

[akhoury]

defeats the purpose of the cache.

it does, if it's happening 100% of the time, but like i mentioned, when in development, it's happening 5% of the time, so.. not too bad.

and when CI building, I am ok cleaning and building without cache (you might not be in your case)

[rkingon]

you should be using separate configs for your build & your dev... only use this for your dev config and you won't need to clear at all during the build.

your prod does things like concat, minify, etc

your dev does things like caching

[mvgijssel]

you should be using separate configs for your build & your dev... only use this for your dev config and you won't need to clear at all during the build.

your prod does things like concat, minify, etc

your dev does things like caching

True! And we have separate configs just for this.

it does, if it's happening 100% of the time, but like i mentioned, when in development, it's happening 5% of the time, so.. not too bad.

and when CI building, I am ok cleaning and building without cache (you might not be in your case)

One of the bigger benefits of this plugin is that we save a lot of CI time. It's the first plugin to actually save significant time in building assets, which is blocking before we can parallelise our test suite.

[FengXianGuo]

I have the same problem, it's happening 100% of the time, I got same error:

TypeError: Cannot read property 'indexOf' of undefined
    at splitQuery (/Users/user/work/moviepro-h5/node_modules/_loader-runner@2.3.1@loader-runner/lib/LoaderRunner.js:19:14)
    at getContext (/Users/user/work/moviepro-h5/node_modules/_loader-runner@2.3.1@loader-runner/lib/LoaderRunner.js:238:17)
    at new NormalModule (/Users/user/work/moviepro-h5/node_modules/_webpack@2.7.0@webpack/lib/NormalModule.js:67:18)
    at Object.thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/serial.js:200:12)
    at Object.thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/serial.js:217:25)
    at Compiler.pluginCompat.tap (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30)
    at Compiler.applyPluginsWaterfall (/Users/user/work/moviepro-h5/node_modules/_tapable@0.2.9@tapable/lib/Tapable.js:92:24)
    at Object.exports.call (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38)
    at thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/SystemArchetype.js:126:29)
    at fetch (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/SystemArchetype.js:173:16)

[limuen]

Oh no, I encountered this issue 100% during my testing. I entered the wrong code in vscode, but when the browser prompted me to delete the wrong code, I couldn't run it due to an error TypeError: Cannot read property 'indexOf' of undefined