Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReferenceError: Can't find variable: webpackJsonp #24

Closed
Devric opened this issue Sep 10, 2014 · 17 comments
Closed

ReferenceError: Can't find variable: webpackJsonp #24

Devric opened this issue Sep 10, 2014 · 17 comments

Comments

@Devric
Copy link

Devric commented Sep 10, 2014

keep on getting this error, where is webpackJsonp defined?

and i've tried with a clean test file with just this one line

describe('unit test', function(){})

and it still complains ReferenceError: Can't find variable: webpackJsonp at line 12

Im using phantomjs

@sokra
Copy link
Contributor

sokra commented Sep 10, 2014

Can you post your configuration?

@simple10
Copy link

I was also running into this when using CommonsChunkPlugin in webpack. Disabling CommonsChunkPlugin when running in karma works.

@rodleviton
Copy link

I am having the same issue and removing CommonsChunkPlugin temporarily fixes issue. Any idea how to make this work with CommonsChunkPlugin?

@sokra
Copy link
Contributor

sokra commented May 10, 2015

Any idea how to make this work with CommonsChunkPlugin?

CommonsChunkPlugin doesn't change the behavior, it's only for optimized loading. So disabling is propably the best way.

@OEvgeny
Copy link

OEvgeny commented Jun 14, 2015

I have this issue too. Tried to use CommonsChunkPlugin to separate third party libraries from tests, but no luck.

@sokra
Copy link
Contributor

sokra commented Jun 21, 2015

CommonsChunkPlugin is not compatible with karma-webpack. Just remove it.

CommonsChunkPlugin is only an optimization, it doesn't have effect on the executation.

@mrsum
Copy link

mrsum commented Feb 20, 2016

So, maybe somebody know how can i organize separated vendors.js and *.spec.js files?
I think it's good for performance cause if project has more than 100 specs file, and all files has contains all vendors code with test describes and testable code – in my case is ~2mb per each file.
Simple calculations will representative. 2 * 100 ~= 200mb of code where 98% lines will be duplicate.

@CobeLapierre
Copy link

You can solve this problem by changing the order of your files loaded into your Karma browser.

karma.conf.js

files: [
'build/shared.js',
'build/*/.js',
]
Shared (in my case) is the file where "webpackJsonp" is defined. By putting this one at the top of the files it will be loaded before the other js files. Solving the error of CommonChunksPlugin.

@jotaoncode
Copy link

It seems that @carbosound1 could be right. I saw a little implementation of what he says. Although it would be great If @carbosound1 share a repo with CommonsChunksPlugins working correctly with karma, so he can bring to light how to solve this issue.

@joeyrobert
Copy link

I've seen this error when using webpack-split-by-path also. Not sure if that uses CommonsChunksPlugins under the hood, but removing it fixes the issue.

@DaveEmmerson
Copy link

@carbosound1 is definitely correct. If you just look at your bundles and find the one that defines webpackJsonp, then put that first in your karma config's files, you're fine. The one passed to the CommonChunksPlugins constructor in the webpack config did the trick here.

@jayrmotta
Copy link

jayrmotta commented Nov 1, 2016

const devConfig = require('./webpack.dev.config');

const commonsChunkPluginIndex = devConfig.plugins.findIndex(plugin => plugin.chunkNames);
devConfig.plugins.splice(commonsChunkPluginIndex, 1);

// ...

webpack: devConfig,

// ...

I had to do this because my webpack.dev.config inherits from a common one which loads the CommonsChunkPlugin. This is not pretty but it's working 😄

@begincalendar
Copy link

I'm also using webpack-split-by-path, but I'm not using the CommonsChunkPlugin.

I think the problem for me is that I can't specify the vendor bundle in the files config option, because it doesn't exist at the time when Karma tries to find it, but instead is created after webpack pre-processing.

@joeyrobert How are you using webpack-split-by-path and ensuring that the vendor bundle gets loaded before anything else?

@joshwiens
Copy link
Contributor

The ability to use commons chunk will be covered in v3 and by use, I mean not having to remove it for those that don't want to run multiple webpack configs. As Tobias said above, CommonsChunk has not real effect on execution.

There is an open issue for this already in the milestone & @jayrmotta has a viable work around here - #24 (comment)

Klaster1 added a commit to gridgain/apache-ignite that referenced this issue Apr 28, 2017
webpack chunk plugin has to be removed during test runs due to incompatibility issues.
codymikol/karma-webpack#24 (comment)
Klaster1 added a commit to gridgain/apache-ignite that referenced this issue Apr 28, 2017
webpack chunk plugin has to be removed during test runs due to incompatibility issues.
codymikol/karma-webpack#24 (comment)
@BuonOmo
Copy link

BuonOmo commented Jul 28, 2017

There is an open issue for this already in the milestone

For these who are trying to find it in order to suscribe the issue, it is #22.

@DmitryGonchar
Copy link

DmitryGonchar commented Dec 10, 2017

@jayrmotta Why not use plugin instanceof webpack.optimize.CommonsChunkPlugin instead of detecting type by whether it has a property?

@albancho
Copy link

albancho commented Jan 15, 2019

I did this piece of code to remove a list of plugins (only one for now, but who knows...), based on plugin.constructor.name:

const disabledPluginNames = [
  'CommonsChunkPlugin'
]
let generatedCommonConfig = commonConfig(envOptions);
generatedCommonConfig.plugins = generatedCommonConfig.plugins.filter(plugin => !disabledPluginNames.some(pluginName => pluginName === plugin.constructor.name));
return generatedCommonConfig;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests