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

Error after upgraded to Meteor 0.9.1 #2521

Closed
victorleungtw opened this Issue Sep 5, 2014 · 20 comments

Comments

Projects
None yet
10 participants
@victorleungtw

victorleungtw commented Sep 5, 2014

After upgraded Meteor from 0.9.0.1 to 0.9.1, I got the following errors in console:

Uncaught TypeError: Cannot read property 'registerHelper' of undefined Uncaught TypeError: Cannot read property 'T9n' of undefined Uncaught TypeError: Cannot read property 'AccountsEntry' of undefined Uncaught ReferenceError: Template is not defined Uncaught ReferenceError: Meteor is not define Exception in defer callback: ReferenceError: Spacebars is not defined

It seems that the changes are not backwards compatible.

@glasser

This comment has been minimized.

Member

glasser commented Sep 5, 2014

@timtch

This comment has been minimized.

timtch commented Sep 5, 2014

I think this is related to this Differential/accounts-entry#263

@Waiski

This comment has been minimized.

Waiski commented Sep 5, 2014

This is apparently caused by some specific combinations of packages. At least one such combination can be reproduced by using alanning:roles and the (deprecated) handlebars-package:

  1. meteor create test
  2. cd test
  3. meteor add alanning:roles
  4. meteor add handlebars
  5. meteor

Gives this in the browser console:

Uncaught TypeError: Cannot call method 'registerHelper' of undefined roles_client.js:78
Uncaught TypeError: Cannot read property 'Roles' of undefined global-imports.js?deeb1da1a09d1b00c4f637319ceafb4152a3ce2b:3
Uncaught ReferenceError: Template is not defined template.test.js?e119ff8df948cfe8167f49eb28794995a594841c:2
Uncaught ReferenceError: Meteor is not defined test.js?a4ef596255404350be2cc45303caea02f934cd17:1

Neither of these packages alone will do, but together they seem to crash. It's not just the deprecated handlebars-package that's to blame though, since in my app with the following packages (all at their latest version):

standard-app-packages
insecure
mrt:jquery-ui
mrt:filesaver
natestrauser:font-awesome
accounts-base
accounts-password
less
mrt:iron-router-progress
mrt:jquery-ui-bootstrap
iron:router
mrt:accounts-admin-ui-bootstrap-3
aslagle:reactive-table
zimme:select2-bootstrap3-css
stylus
mrt:just-i18n
alanning:roles
accounts-ui
natestrauser:select2
simison:bootstrap3-less

There are the same problems (with much more of the similar error messages) too. I'm yet to figure out which packages exactly are the ones causing the problem.

@gibex

This comment has been minimized.

gibex commented Sep 5, 2014

alanning:roles package is causing these errors for me.

@kkukielka

This comment has been minimized.

kkukielka commented Sep 5, 2014

Workaround for now (working with Accounts-Entry):

  • change package name handlebars to templating
  • change beginning of the file t9n.coffee in account-t9n from:
if Meteor.isClient
  if Package.ui
    Handlebars = Package.ui.Handlebars

  Handlebars.registerHelper 't9n', (x) ->
    T9n.get(x)

to:

if Meteor.isClient

  Handlebars.registerHelper 't9n', (x) ->
    T9n.get(x)
@aaronjudd

This comment has been minimized.

aaronjudd commented Sep 5, 2014

See: alanning/meteor-roles#53

The problem (mostly) is that Package.ui.UI is not defined in 0.9.1, instead only Package.blaze.UI works.

@alanning

This comment has been minimized.

Contributor

alanning commented Sep 5, 2014

There is a PR by @aldeed which resolves the issue for 0.9.1: alanning/meteor-roles#54

I won't be merging it into master until we can make it backwards compatible but hopefully we can figure out a way to do that soon.

If anyone has suggestions on how to make a check for whether blaze@2.0.0 is available (similar to the uiExists one for the ui package that we already have here), that would be very helpful!

I really hope there is a way to do that as I don't think its reasonable to maintain two code-bases. Try-catch around the api.use(['blaze@2.0.0']...) doesn't work and results in this error when run in previous versions of Meteor:

While building package `roles`:
error: no such package: 'blaze@2.0.0'
@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 5, 2014

@alanning, for pre-0.9.0, could do:

if (api.versionsFrom) {
  api.use(['blaze@2.0.0'], 'client', {weak: true});
}

But that would also get run for 0.9.0 and 0.9.0.1, both of which don't have a blaze package I think? Or maybe they did.

@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 5, 2014

I think they did have blaze, but you'd probably want to use @1.0.0 for those versions.

@alanning

This comment has been minimized.

Contributor

alanning commented Sep 5, 2014

Yeah, I arrived at the same conclusion. Not sure about 0.9.0 vs 0.9.1; I think we'll just have to test them and see what works.

@alanning

This comment has been minimized.

Contributor

alanning commented Sep 5, 2014

If we can define a range for the supported package versions, then I think we're good to go. Anybody know how to do that?

The issue is that the roles package can support blaze@1 and blaze@2 but it seems we have to specify one or the other which means we can't support both 0.9.0 and 0.9.1 (which would just be silly).

Alternately, we could leave off the specific version info for blaze if there is a way to tell Meteor to use the same Meteor Version as the app. For example,

if (api.versionsFrom) {
  api.versionsFrom("METEOR@<Whatever the app is using>");
  api.use(['blaze'], 'client', {weak: true});
}
@alanning

This comment has been minimized.

Contributor

alanning commented Sep 5, 2014

@avital

This comment has been minimized.

Contributor

avital commented Sep 6, 2014

Here's what happened: We moved a bunch of stuff from the ui package to the blaze package, but kept backwards compatibility with the old APIs. The problem is -- packages like alanning:roles that have a weak dependency on ui contain code like Package.ui.UI. Since the UI global is now defined in the blaze package, that no longer works.

We plan to release 0.9.1.1 that addresses this concern (and a few others) -- we'll just make sure to also export those globals from the packages where they used to be exported. That will bring 0.9.1.1 to full backwards compatibility with 0.9.0, including for packages with weak dependencies.

Expect 0.9.1.1 very soon.

@alanning

This comment has been minimized.

Contributor

alanning commented Sep 6, 2014

It seems removing both the call to api.versionsFrom and any specific version for the blaze package gets blaze working for Meteor 0.9.0, 0.9.0.1, and 0.9.1.

  if (api.versionsFrom) {
    api.use(['blaze'], 'client', {weak: true});
    ...

Source: https://github.com/alanning/meteor-roles/blob/meteor-0.9.1/roles/package.js#L14

Please help test the meteor-0.9.1 branch, which contains @aldeed's PR plus backwards compatibility fixes. To use the version locally, clone the repo, switch to the meteor-0.9.1 branch, and manually symlink to the "roles" directory from your app's "packages" directory.

@avital, our overall goal is to support all meteor versions as well as meteor without UI from the same codebase. Eliminating any version information for blaze seems to work. Thank you for letting that be possible. If that didn't work we were in the very real possibility of supporting Meteor <0.9.0 and 0.9.1+ but not 0.9.0 or 0.9.0.1.

Is there any way to specify that we support a range of package versions or Meteor versions? Something like,

if (api.versionsFrom) {
  api.use(['blaze@1-2'], 'client', {weak: true});
}

One thing that would make it easier for package authors to maintain backwards compatibility is if the specific version of Meteor could be accessible in package.js through the api object. That would allow for the possibility of workarounds in the case where specific fixes are needed.

@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 6, 2014

I have the need to depend on a package with a range of major versions, too. Seems like a basic requirement we should be able to do.

@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 6, 2014

Actually, I tried @alanning's suggestion of removing api.versionsForm and specific versions for core packages, and although it will run fine locally, meteor publish does not let you publish it. This seems like a pretty big oversight. There is no way to not specify a version and there is no way to specify multiple major versions, so... no way to have your package work on both Meteor 0.9.0 and Meteor 0.9.1.

I would suggest simple ability to specify version ranges for each version piece:

  • @1+.0.0
  • @1-2.0.0
  • @1.0+.0+

And comma support for trickier cases:

  • @1.6+.0+,2.0+.0+
@alanning

This comment has been minimized.

Contributor

alanning commented Sep 6, 2014

This is getting ridiculous. api.versionsFrom as it is now is an anti-pattern and we also can't specify a range for specific packages.

Here is an example repo for people to try these things out with:
https://github.com/alanning/meteor-test-versionsFrom

@avital

This comment has been minimized.

Contributor

avital commented Sep 7, 2014

0.9.1.1 is now released, fixing some of the backwards-incompatibility we accidentally introduced with 0.9.1. Some packages, such as accounts-entry now work without change. Others may still need some tweaks. Apologies for the rough transition.

@avital

This comment has been minimized.

Contributor

avital commented Sep 8, 2014

I believe that the original issue has been resolved with 0.9.1.1. This thread contains a lot of other details -- if any of them are still relevant, definitely open new issues or new threads on the meteor-core mailing list.

@avital avital closed this Sep 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment