Meteor 1.3 require conflicting with jquery plugins

We have a jquery plugin file at /client/lib/plugins/jquery.serialize-object.js

The file is a simple download of the jquery plugin which has AMD and CommonJS wrapping in it. After upgrading to 1.3 we can’t get this file to load on the “client” browser-side without throwing errors. Primarily the error thrown is Cannot find module 'jquery'

This seems to happen for a few other files as well, all these files seem to use CommonJS require keyword which Meteor seems to override.

What is the best way to migrate this properly to 1.3

3 Likes

Try running: meteor npm install --save jquery meteor-node-stubs

This will lead to multiple versions of jQuery being loaded.

Well yes, that installs v2.2.0 of jquery in node_modules which is different from what meteor comes packaged with. Secondly the problem is I still am not able to use the plugin. I don’t understand why this is not mentioned in the migration guide as it seems to be a pretty trivial issue upgrading from 1.2.1

2 Likes

I had the same problem, first running “meteor npm install --save jquery” then just moving my jQuery plugins from “client/lib” to “client/compatibility” solve the problem. :grin:

1 Like

I’m also struggling with this issue. I’m trying to use fullcalendar from npm but it also contains which has a require(“jquery”)

This hack works for me so far:

1) adding my preferred jquery version via cdn into the html itself

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.2/jquery.min.js"></script>

2) overriding the jquery package:
packages/jquery/package.js:

Package.describe({
    version: '1.11.6'
});

Package.onUse(function (api) {

    api.use('modules-runtime');

    api.export('$', 'client');
    api.export('jQuery', 'client');
    api.addFiles('index.js', ['client']);

});

packages/jquery/index.js:

//as we have it added as cdn in the head, jQuery is available
jQuery = window.jQuery;
$ = window.jQuery;


meteorInstall({
    node_modules: {
        jquery: function (r, e, module) {
            module.exports = jQuery;
        }
    }
});

In my case I use angular-meteor, but I think it shouldn’t make any difference. I also quickly scanned the included meteor scripts and the only part it uses jQuery at all is the check todo one call…

If you are going to overwrite Meteor’s jQuery package then why not fix this issue properly by using the official NPM version? I have an issue to get something similar implemented in core (see here) but in the meantime there is nothing stopping us from making the changes locally as you suggested.

the problem with the npm install --save jquery version is that it will not prevent other packages from require the meteor package to require(“meteor/jquery”) therefore you will have two jquery libs loaded currently until it is fixed like in the issue you linked

You don’t need to load jQuery again, the Meteor package only needs to check that it’s installed in the app’s node_modules.

you mean like

import jQueryNpm from 'jquery'

export const jQuery = jQueryNpm
export const $ = jQueryNpm

I tried this but the meteor build script hung at 100% cpu …

@mxab 's solution worked. Although I dont understand what/where to 2nd comment’s code would go…

Can someone explain why removing the atmosphere jquery package doesn’t actually seem to remove jquery?
Even after doing so, it still appears in the list of packages

<script type="text/javascript" src="/packages/jquery.js?hash=22a0055f59bd150c435c5aba34c7c59076b8bcd9"></script>

I’m having similar issues with fullcalendar, and seem to be running two versions of jquery at once, so I was hoping to remove the 1.11.2 version that meteor comes with.
Also, if I try to use fullcalendar from npm, I get a jquery not found error. However, if I copy the fullcalendar js file inside my imports directory and then import that, it works. They are exactly the same file, imported at the same place – what is going on?

1 Like

I had similar problems, first with Bootstrap complaining about JQuery 3, so I removed the npm installed Jquery 3, and manually installed 2.2.4, which then caused fullcalendar to fail, so @noachr’s suggestion of explicitly importing the fullcalendar.js from an imports/lib directory was the fix to make it work again.