Meteor 1.3 *early beta* now available

announce
325

And if you do try it on windows, as I did, this is the message you’ll get:

This project uses Meteor 1.3-rc.1, which isn’t available on Windows. To work with this app on all supported platforms, use meteor update --release METEOR@1.2.1 to pin this app to the newest Windows-compatible release.

326

I have a question:

Is it in general the plan that upgrading from 1.2.1 to 1.3 should be smooth? Or is it expected that apps are going to need to be modified to work in the new npm/modules world?

(I just tested upgrading one of my apps which is reasonably complex to 1.3-rc.1, and it did not work at all)

1 Like
327

This is probably because the packages you use and not Meteor itself, but I am just guesing :wink: Updates was always a little problematic especially in big apps with many community packages.

328

Yes, most probably. This is why I am asking. If it is supposed to be smooth, then maybe the devs wants reported issues. If it’s expected to be bumpy, then I’ll just wait a bit till the dust settles…

329

Report issues when you encounter bugs with latest RC. I just found one when using some 3rd party packages (the bug was in the Meteor itself, though) and reported it :slight_smile:.

330

What are the correct URL format to install cordova plugin in 1.3? I would like to install cordova-plugin-mapbox@1.2.0 from https://github.com/Telerik-Verified-Plugins/Mapbox

331

@vikti: meteor add cordova:cordova-plugin-mapbox@https://github.com/Telerik-Verified-Plugins/Mapbox should work.

332

That’s what is intended: 1.3 should theoretically be backwards compatible, so simply updating should in theory not break your app in most cases. There are exceptions: for example, are you using any packages that depend on the non-public API of Meteor or monkey-patch some Meteor’s APIs during runtime (for example, some SSR packages do this)? If so, then those packages can very easily break from one version of Meteor to the next. The best thing MDG can do is guarantee backwards compatibility with the official public API.

333 
meteor update --release 1.3-rc.2

Release candidate 2 is out.

334

Here is what I get after upgrading to 1.3-rc.1.
Apparently there are issues with the TAPi18n UI helpers, FlowRouter and jQuery Bar Rating - Minimal, light-weight jQuery ratings
All working fine in 1.2.1.

1455×1247 171 KB

335

I tried an upgrade to version 1.3-rc.2 and still got the error from 1.3-beta.16:

It is disingenuous to call it a “release candidate”. Fix it immediately.

336

The issue Cannot find module 'jquery' is, as I understand, due to the fact that another script of yours tries to require / include it, but you didn’t install it via NPM. This worked in 1.2.1 because there was no module system back then, so your script just loaded jQuery from its global variable.

337

Wow! Let me get out my self-entitlement meter… HOLY COW, it’s off the charts!

20 Likes
338

@jesperwe

  • Cannot find module jQuery - Exactly what @M4v3R said: This is because some code uses the require function. 1.3 exposes a global require function in your environment which wasn’t there before 1.3, and so the code (wherever it is) detects that require is available, and tries to use it. You should be able to fix this by simply running
    npm install jquery --save
    then
    meteor remove jquery
    so that you’ll be using jQuery from NPM instead of the Meteor package.
  • There is no route for the path: /: This might go away after the jQuery error is resolved.
  • Cannot convert undefined or null to object - What’s the code there? Maybe that’s solved with fixing jQuery too.
339

Then again, this is a showstopper on Windows. I’m wondering how this one made it through testing.

It’s not that hard to at least spin up a Windows VM and try to at least install Meteor there.

340

Sure. I’m wondering the same thing, because a boilerplate with Flow Router fails to even run at all. But shit happens, and I’m sure the MDG team is feeling pulled in several different directions at the moment. To hurl such utter disrespect at them as they work on a framework offered for free is unacceptable. Especially since no one is twisting anyone’s arm to upgrade past 1.2.

If you want a reasonable level of stability, IMO stick with 1.3 beta 12.

5 Likes
341

I am receiving this error only after running meteor reset

While processing files with cosmos:browserify (for target web.browser):
packages/kadira:flow-router/client.browserify.js: Arguments to path.resolve must be strings

Browserify options:
  undefined

packages/kadira:dochead/package.browserify.js: Arguments to path.resolve must be strings

Browserify options:
 undefined
342

Rethink the definition of a “release candidate”. After 3 release candidates (0, 1, 2) it still doesn’t work at all for many people (Windows users it appears). It probably should have remained labeled as beta, as most of us would expect a release candidate (even the first one) to mostly work.

343

No disagreement there.

344

Take the latest version of flow-router-ssr 3.12.1 i think. That problem has been solved.