Don't fail if sources are included

[nikku]

If sources are included in the files / preprocessors section in a karma.conf.js karma fails to start with

Chrome 38.0.2125 (Linux) ERROR
  Uncaught Error: Cannot find module '/full/path/to/file.js'
  at /tmp/e23abc7c0b33cd65128e2f9d77ad57525fd1fdbe.browserify:1

This looks like a regression (was supposed to work in karma-bro <= 0.10.

See #51 and #50.

[nikku]

The issue can be fixed by switching to absolute path for the require stubs and exports. This however breaks with file content inlines (see browserify/brfs#37).

[nikku]

Using relative path + browserify.exposeAll=true fixes the issue, too but breaks browserifies external configuration. Life is hard.

[nikku]

Recent [email protected] fixes for abs path break the detection of deleted files (in watchify). Still no fix for this issue in sight.

@bendrucker Good you fixed our example for now. We should re-install the commit once this issue is resolved. Having these "special" setups in the examples repository (including a big warning note) is the only way we can verify newer versions of browserify do not break things (including custom-made special setups).

[bendrucker]

Given the constant shifting in browserify's internals we should have the normal unit tests and then smoke test suites (versus leaving stuff in example).

[nikku]

Good call. I will create an extended smoke test version of the example project somewhere in the test directory.

[nikku]

Well, this issue is a blocker for me.

It can easily make your test-suite fail, if you include helpers or mock date with your tests:

test/spec/someMock.js
test/spec/someSpec.js

With our current behavior, if someSpec.js requires someMock.js the library will fail with a cannot find module/abs/path/to/someMock.js`.

[nikku]

Stuff is fixed on the 52-fix branch.

@bendrucker Could you have a look at it?

I'd love to release this as version 2.0.0 as it appears to me as if this is the most stable karma-browserify since karma-bro 0.6.x. 😃

[bendrucker]

Looks great. One question:

Are you sure that external needs to be called in 'prebundle'? I can't track down where b._external is emptied/dereferenced on 'reset'.

[nikku]

Just a precaution in case of changing browserify internals ;-)

[bendrucker]

I think it's unlikely to be meaningful to have a minor memory leak there so it's okay to change

[ijse]

@nikku Hi, this problem still exist in [email protected], but it's ok for 1.0.1.

[nikku]

Hmm, we have got some integration tests that report it is fixed.

Could you open another issue with hints on your test setup and ways to reproduce the behavior you are experiencing?

[ijse]

@nikku To reproduce this is very simple. I just use @estekhin repo: https://github.com/estekhin/sandbox-karma-browserify

and change karma.conf.js:

λ git diff
diff --git a/karma.conf.js b/karma.conf.js
index f1708e5..11a1d4e 100644
--- a/karma.conf.js
+++ b/karma.conf.js
@@ -4,11 +4,11 @@ module.exports = function( config ) {

         basePath : '',
         files : [
-            'src/**/*.js'
+            'src/**/*.spec.js'
         ],

         preprocessors : {
-            'src/**/*.js' : [ 'browserify' ]
+            'src/**/*.spec.js' : [ 'browserify' ]
         },
         browserify : {
             debug : true

Then you can use two versions to reproduce it.

PS: I use win7 with node v0.10.25.

[nikku]

Works for me in either configuration.

[rubenhazelaar]

Had the same issue. After some digging around the cause seems to be in the browserify version (7.0.3), forced it to work with 8.0.3 and it seems to work properly now. Don't know what the exact reason could be.