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.
Wow! Let me get out my self-entitlement meter… HOLY COW, it’s off the charts!
20 Likes
-
Cannot find module jQuery - Exactly what @M4v3R said: This is because some code uses the
requirefunction. 1.3 exposes a globalrequirefunction in your environment which wasn’t there before 1.3, and so the code (wherever it is) detects thatrequireis available, and tries to use it. You should be able to fix this by simply running
thennpm install jquery --save
so that you’ll be using jQuery from NPM instead of the Meteor package.meteor remove jquery - 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.
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.
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
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:
undefinedRethink 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.
No disagreement there.
Take the latest version of flow-router-ssr 3.12.1 i think. That problem has been solved.
Thanks. That removed the Cannot find module jQuery error.
The others did not go away, however.
The FlowRouter v2 branch is also fixed in v2.11.0
Release candidate running smooth for me now!
Anyone else running into this problem with the latest RC?
While building package mwc-compiler:
error: couldn't install npm package mkdirp@0.5.1: Command failed: 'C:\Users\Andreas' is not recognized as an
internal or external command,
operable program or batch file.
'C:\Users\Andreas' is not recognized as an internal or external command,
operable program or batch file.
While building plugin `compile-ext` in package `mwc-compiler`:
error: couldn't install npm package chokidar@1.2.0: Command failed: 'C:\Users\Andreas' is not recognized as an
internal or external command,
operable program or batch file.
'C:\Users\Andreas' is not recognized as an internal or external command,
operable program or batch file.@jesperwe In my experience, I find that the FlowRouter error happens because some other error prior to your routes being set up happens, and prevents your FlowRouter setup code from happening. In my cases (it’s happened a bunch) I fix some other error, and FlowRouter then works. What do your errors look like now?
In my mind, as the one putting out these releases, “release candidate” implies no new features will be added before the official release, not that the RC is totally bug-free. Sorry for any confusion there.
13 Likes
From wikipedia :
A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug
However if you want a stable release you have to use a final release, not a version intended for testing as is a release candidate.
4 Likes
Interesting, thanks for that definition! So then RC1 and RC2 are not, in fact, release candidates 
(since they both have show-stopper bugs)
1 Like
What is the best place to know what is the latest available version of the 1.3 beta? At the moment I’ll see people talking about beta.11 or rc2 and then search for them.
Is this the official MDG stance on the definition of a “release candidate”?
Nobody ever said that we expect a release candidate to be bug-free. You are putting words into our mouths in a desperate attempt to defend yourself.
Nobody expects a release candidate to be dead-on-arrival as the first 3 have been. It would even be bad to see in a beta release (but we’d be more forgiving). The problem was never fixed since it arose in beta.16, when really it should have been fixed before the first release candidate. These are the basis of our disappointment.
It feels as if the only reason to why you started labeling the most recent releases as “release candidate” was in order to appear to meet a deadline to start releasing a “release candidate” by a specified date.
I was reminded of this post: http://hueniverse.com/2016/01/26/how-to-use-open-source-and-shut-the-fuck-up-at-the-same-time/
7 Likes
I’m glad you care enough about this release to be so disappointed, and I’m glad you let me know.
You may be onto something there. I definitely am eager to see this release finished and ship it sooner rather than later, and my foresight about the work that’s left certainly isn’t perfect. But a bug that totally ruins your developer experience during an explicit pre-release testing period is a bug that absolutely will be fixed before the final release. Now, it’s my prerogative to release additional betas or candidates or whatever we should be calling them, even if they don’t fix that particular bug, because I want to check my sanity about other bugs, or I just haven’t found the right solution to the bug you care most about. Take me to task if 1.3 is dead-on-arrival for you, but please, please bear with me while we get there.
20 Likes