Don't fail if sources are included about karma-browserify HOT 15 CLOSED

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).

from karma-browserify.

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

from karma-browserify.

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).

from karma-browserify.

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).

from karma-browserify.

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

from karma-browserify.

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`.

from karma-browserify.

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. 😃

from karma-browserify.

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'.

from karma-browserify.

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

from karma-browserify.

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

from karma-browserify.

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

from karma-browserify.

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?

from karma-browserify.

@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.

from karma-browserify.

Works for me in either configuration.

from karma-browserify.

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.

from karma-browserify.