[Solved] jquery not found and 3rd part code broken after 1.3 update


#1
=> Started proxy.                             
                                              
Unable to resolve some modules:

  "jquery" in /app/client/lib/daterangepicker.js (web.browser)
  "moment" in /app/client/lib/daterangepicker.js (web.browser)
  "../moment" in /app/client/lib/moment-locales/fr.js (web.browser)
                                              
Consider running: meteor npm install --save jquery moment

Both are declared in ./meteor/packages

jquery                  # Helpful client-side library
momentjs:moment         # Client and server Date management

I tried

  • running meteor npm install --save jquery moment as suggested
  • adding an import in daterangepicker.js as suggested here

None of them worked

The code of daterangepicker.js starts trying to find jquery and moment but I don’t know enough JavaScript to be able to understand what is happening and how to fix it.

(function (root, factory) {

    if(typeof define === 'function' && define.amd) {
        define(['moment', 'jquery', 'exports'], function (momentjs, $, exports) {
            root.daterangepicker = factory(root, exports, momentjs, $);
        });

    } else if(typeof exports !== 'undefined') {
        var momentjs = require('moment');
        var jQuery;
        try {
            jQuery = require('jquery');
        } catch(err) {
            jQuery = window.jQuery;
            if(!jQuery) throw new Error('jQuery dependency not found');
        }

        factory(root, exports, momentjs, jQuery);

        // Finally, as a browser global.
    } else {
        root.daterangepicker = factory(root, {}, root.moment, (root.jQuery || root.Zepto ||
            root.ender || root.$));
    }

}(this, function (root, daterangepicker, moment, $) {

#2

I just updated to Meteor 1.3 as well and am experiencing the same problems. As the author already pointed out this has to do with the new ES2015 modules support. I did as instructed in the guides and at least the error message about the missing jquery and moment modules is gone. But they are still not available to my (external) .js files. I’m running CLNDR and since upgrading the calendar is not shown anymore.

The whole thing about the module support ist very confusing and breaks a lot of code. I ran meteor npm init as instructed and it asked me a lot of questions. I don’t have a fixed version number yet, why do I need to provide one? What about this entry point? Which is the entry point in a Meteor application that is spread across multiple files? Is it safe to use any filename for this? Even those that don’t exist? Where do I need to put the import statements?


#3

I had the same problem. Doing the
meteor npm install --save jquery moment
and moving daterangepicker to client/compatibility directory fixed everything.


#4

The first issue (meteor npm install --saved jquery moment not removing the error message) was solved by moving the generate folder node_modules to the root of the project. In my case it was being generated elsewhere due to the way I call meteor via scripts

The second issue (3rd part code not working including datepicker, calendar, etc) was solved by moving all 3rd part code to client/compatibility as suggested


#5

Unfortunately this didn’t help either. I tried all your suggested ways and still CLNDR and other 3rd party libraries don’t get loaded. I also tried installing CLNDR via meteor npm install --save clndr and load it in a file I called client/compatibility/init.js with import clndr from 'clndr'; No joy. Is there any complete guide on how to do this? I suppose I’m missing a crucial step.


#6

Actually, so it looks like this should not be marked as [solved]?

I am also a bit confused about how we should best be migrating our existing applications which may use NPM and/or browserify to the new 1.3 framework… Can someone (ideally from MDG) please write an article/guide for the correct way to go about this?

Thanks
Rick


#7

I have the same issue upgrading:

Unable to resolve some modules:

“jquery” in /…/client/lib/jquery.inputmask.bundle.js (web.browser)
“dependencyLib” in /…/client/lib/jquery.inputmask.bundle.js (web.browser)
“inputmask” in /…/client/lib/jquery.inputmask.bundle.js (web.browser)


#8

The changes suggested did solve my migration issue which is why I marked the issue as solved. That said, let’s review the different elements

Before migration

  • 3rd part code in /client/lib (datarangepicker, fulllcalendar, moment internationalisation files). Those files were taken from their respective source distribution and put non-minified in /client/lib as if I had written them.
  • The files had dependencies on librairies (jquery, moment)
  • Libraries I had installed via .meteor/packages

in .meteor/packages

meteorhacks:npm
jquery
momentjs:moment

After migration with meteor update

I was getting this message

=> Started proxy.                             
                                              
Unable to resolve some modules:

  "jquery" in /app/client/lib/daterangepicker.js (web.browser)
  "moment" in /app/client/lib/daterangepicker.js (web.browser)
  "../moment" in /app/client/lib/moment-locales/fr.js (web.browser)
                                              
Consider running: meteor npm install --save jquery moment

What I did was

  • remove meteorhacks:npm and npm-container from .meteor/packages and all related files and folders (/packages, packages.json)
  • remove jquery and moment from .meteor/packages
  • run the suggested command meteor npm install --save jquery moment
  • move the generated node_modules to the root of the project /app because the meteor command doesn’t check that you are in the right folder (unlike meteor run) and mine had been created outside of the /app folder
  • have a look to node_modules and check what was installed. I noticed the moment installation already had the internationalisation files so I could delete them from /client/lib

That got rid of the error messages and allowed me to run the code again. However, the 3rd part code still wasn’t finding jquery and moment, therefore wasn’t working

Then I moved all those 3rd part files from client/lib into client/compatibility


#9

Thanks for your writeup. But this is exactly what I have done before and it doesn’t work. I just did it again to make sure I didn’t miss something. Still, my 3rd party libraries won’t be loaded and can’t be executed. I don’t see Unable to resolve some modules during startup anymore, but when accessing the webpage the error console consists of errors like ReferenceError: Can't find variable: moment and I can’t see my clndr.

By the way. What is it about meteor npm init (package.json)? The documentation asks us to do so, but most practical guides don’t use it.

And what about include moment from 'moment';? Won’t we need this as well?


#10

I had a look to the clndr source code and it looks similar to daterangepicker.js in the way it looks for the existing libraries

(function (factory) {
    // Multiple loading methods are supported depending on
    // what is available globally. While moment is loaded
    // here, the instance can be passed in at config time.
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        define(['jquery', 'moment'], factory);
    }
    else if (typeof exports === 'object') {
        // Node/CommonJS
        factory(require('jquery'), require('moment'));
    }
    else {
        // Browser globals
        factory(jQuery, moment);
    }
}(function ($, moment) {

Can you run a version of the code in 1.2 and put a console.log statement in each branch to see which one it calls ? In my case it was calling the Node/CommonJS branch.

That said, I installed CLNRD in my migrated application and it worked

  • I put the files from the distribution CLNDR-master/src/clndr.js and CLNDR-master/demo/css/clndr.css in /app/client/compatibility/
  • I added a <div class="cal1 parent-element"></div> in my splash template
  • I added Template.splash.onRendered(function () { $('.parent-element').clndr() }) in my js controller

If I put clndr.js in /client/lib instead i get TypeError: $(…).clndr is not a function because the template onRendered doesn’t find the clndr declaration as Meteor 1.3 doesn’t make global variables global anymore.


#11

I am myself COMPLETELY CONFUSED about how my application should be migrated to 1.3 : the /client/compatibility folder is just a workaround that has existed for a long time, I missed it because it’s poorly documented and till now throwing 3rd part code into /client/lib just worked.


#12

In Meteor 1.2 the last branch (Browser globals) is being called.

In Meteor 1.3 no branch is called. I can confirm that the `TypeError … is not a functiondoesn't appear if the 3rd party code is insideclient/compatiblity``. But that doesn’t stop the code from not working. :frowning: Under this circumstances Meteor 1.3 shouldn’t have been released at all.


#13

You are right, it passes by the global case in both 1.2 and 1.3 for me.

The fact that I made the same library work in 1.3 following the steps that solved my issues for daterangepicker, fullcalendar and those of Izydorr as well seem to indicate that the problem might not come from Meteor itself but from the way you made the calendar work in 1.2

Can you give a little bit more of details about the errors in the console and the organization of the code ?


#14

It’s likely that the failure is on my end, but I have no idea how to debug it. I just created a new Meteor 1.3 project doing nothing more than including CLNDR.js the way you suggested it. Same problem.

This is what I changed after running meteor create test:

    meteor npm install --save jquery moment
    mkdir -p client/compatibility
    cd client/compatiblity
    wget https://github.com/kylestetz/CLNDR/raw/master/src/clndr.js
    // changes to client/main.js
    // ...
    Template.hello.rendered = function () {
      $('#clndr').clndr();
    }

Please note: Using onRendered instead of rendered is giving me the same results.

    // changes to client/main.html
    // ...
    <h1>Welcome to Meteor!</h1>
    {{> hello}}
    {{> info}}
    <div id="clndr"></div>
    // ...

That’s it. I just added an HTML element to the template and ran the added CLNDR function on it. But even this doesn’t work. The CLNDR won’t be displayed and the JS error console displays ReferenceError: moment is not defined.

What am I doing wrong? This is giving me headaches. By the way, I tried import moment and jquery as well, but this didn’t help either. What is the import { Template } from 'meteor/templating'; for? When updating my own Meteor app this is not needed for using templates?


#15

I confirm it doesn’t work when following those steps.

I made it work by adding momentjs:moment to .meteor/packages


#16

The new 1.3.1 fixes this for me!
You don’t need the client/compatibility … any folder under client (I use lib) now works (for me)


#17

Is there any special way to update to 1.3.1? I just did meteor update and 3rd party code still needs to be in client/compatibility to be executed. By the way, where are the changelogs for Meteor? Looking at the commits at Github it seems like the only change from 1.3.0 to 1.3.1 stable (including the RCs) was an increase in version numbering. :worried:


#18

Thanks. Adding momentjs:moment does help, now clndr does work when run as 3rd party code in client/compatibility. I also tried adding it via meteor npm install --save clndr, but this doesn’t work. It seems like that the only package installed through npm that is working is jquery. Most likely jquery is included already and the npm plugin thingy doesn’t work after all. :confused:

I already tried including the other libs via import { clndr } from 'clndr'; in a file called client/main.js, but this doesn’t seem to change anything. Also this seems to have conflicts for npm packages like bootstrap-select because of the hyphen.


#19

update --release 1.3.1


#20

Thanks! I updated to Meteor 1.3.1, but this doesn’t fix anything for me. TypeError $(...).clndr is not a function when clndr.js is in any other path than client/compatibility. Installing it via NPM doesn’t work as well.