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

[MeteoRick]

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

[stocksp]

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)

[diegoolivier]

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

[alexschomb]

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?

[diegoolivier]

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.

[diegoolivier]

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.

[alexschomb]

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. Under this circumstances Meteor 1.3 shouldn’t have been released at all.

[diegoolivier]

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 ?

[alexschomb]

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?

[diegoolivier]

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

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

[stocksp]

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)

[alexschomb]

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.

[alexschomb]

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.

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.

[stocksp]

update --release 1.3.1

[alexschomb]

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.

[stocksp]

Did you see my post yesterday?

Why your JQuery plugins may be failing in 1.3.1

Of the ten plugins that run fine in a 1.2.1 in production app, three will never run in 1.3.1 without being hacked. First one bootstrap3-typeahead.js v3.1.0 This one causes a Meteor build failure with a suggestion to install jquery Here is the first few lines (for those that want the details): if (typeof module !== 'undefined' && module.exports) { module.exports = factory(require('jquery')); } // AMD module is defined else if (typeof define === 'function' && define.amd) { defi…

You MAY have the same issue. If you look at the source (maybe put some console.logs) it may answer the question of why you are having so much grief.

[diegoolivier]

Use the workaround and wait for MDG to investigate all issues created by migration to 1.3

As long as your code works, IMHO, your are good until we get more information.

[thebarty]

just saying that I stumbled upon something similar with incuding select2 AFTER migration to 1.3.

For me the only working solution right now is to load the library via CDN in - adding it via npm does NOT work for me.

this is the select2-problem on github https://github.com/aldeed/meteor-autoform-select2/issues/65

[alexschomb]

Thanks for all your answers. It’s likely that my jQuery plugins have the same problem as those pointed out by @stocksp. For the moment I’ll go with the workaround and hope for a better Meteor 1.3.2.

I opened a GitHub issue for CLNDR as well: https://github.com/kylestetz/CLNDR/issues/257

[diegoolivier]

I actually was able to remove the momentjs:moment from .meteor/packages and just use the one installed by meteor npm install --save moment

I added a file npm_modules.js in /lib containing

moment = require('moment')

All 3rd part libraries find the global variable