This might solve your issue:
If I’m correct, this would still require you to change the .jsx extensions into .js, but the you can omit the extension in your imports. So still work, but no code changes 
Thanks! I think I prefer to have JSX files to have a jsx extension though. And I already made the changes anyway 
Is there a way to opt out of WKWebView / remove it. I know of at least one cordova plugin that simply doesn’t work with WKWebView yet. (cordova-google-maps)
@pmwisdom: Not currently. From this issue, it seems the incompatibility of cordova-plugin-googlemaps is with Cordova iOS 4 (which we use), not WKWebView specifically (so it wouldn’t work with UIWebView either).
Deploying a Meteor 1.3 app to my hosting provider (IBM Bluemix) fails. Is it because the release version is hardcoded as RELEASE="1.2.1" in the script at install.meteor.com?
Wouldn’t it be better if it could detect the exact version of Meteor that the app being deployed uses and install that?
I just wanted to mention Meteor 1.3 beta 12 is now available, which should fix some issues for people. You can update by running meteor update --release 1.3-beta.12 in the app directory.
7 Likes
I get the following after updating to Beta 12 (Beta 11 worked fine!):
=> Started proxy.
Error: sourcePath not a file: bootstrap/js/transition.js
at ImportScanner._ensureSourcePath (/tools/isobuild/import-scanner.js:208:13)
at /tools/isobuild/import-scanner.js:101:28
at Array.forEach (native)
at ImportScanner.addInputFiles (/tools/isobuild/import-scanner.js:100:11)
at /tools/isobuild/compiler-plugin.js:709:15
at Array.forEach (native)
at Function.computeJsOutputFilesMap (/tools/isobuild/compiler-plugin.js:689:19)
at ClientTarget._emitResources (/tools/isobuild/bundler.js:749:8)
at /tools/isobuild/bundler.js:516:12
at /tools/utils/buildmessage.js:359:18
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:352:34
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:350:23
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at Object.enterJob (/tools/utils/buildmessage.js:324:26)
at ClientTarget.make (/tools/isobuild/bundler.js:507:18)
at /tools/isobuild/bundler.js:2232:14
at /tools/isobuild/bundler.js:2322:20
at Array.forEach (native)
at Function._.each._.forEach (/Users/siyfion/.meteor/packages/meteor-tool/.1.1.13-beta.12.14gk7rd++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
at /tools/isobuild/bundler.js:2321:7
at /tools/utils/buildmessage.js:271:13
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:264:29
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:262:18
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at /tools/utils/buildmessage.js:253:23
at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
at Object.capture (/tools/utils/buildmessage.js:252:19)
at Object.exports.bundle (/tools/isobuild/bundler.js:2213:31)
at /tools/runners/run-app.js:586:36
at Function.run (/tools/tool-env/profile.js:489:12)
at bundleApp (/tools/runners/run-app.js:576:34)
at AppRunner._runOnce (/tools/runners/run-app.js:629:35)
at AppRunner._fiber (/tools/runners/run-app.js:881:28)
at /tools/runners/run-app.js:406:12
Immediate, noticeable difference and already massively easier to manage load order; thanks MDG!
Same here with this file Error: sourcePath not a file: push.config.web.browser.js
Beta 12 rocks! Impressive build times for sure. Great work, team!
Hi Marc, I have the same Issue with raix:push, see here: https://github.com/meteor/meteor/issues/6411 and here: https://github.com/raix/push/issues/185 - a possible workaround is to remove the config.push.json - file and call Push.Configure() manually. But I’m actually not very familiar with the package and I’m a bit stumped about how to configure the client. If you get it done, it’d be great if you could post a short example here and/or on one of the tickets.
KTHXBYE!
So what’s the status of testing in beta.12? I’m trying to run a unit test using:
meteor test --driver-package avital:mocha
and all I get is a forever spinner. Is it not expected to be working now or am I doing it wrong or what?
Update:
It’s not just spinning forever. Only for about 10 minutes before it started loading packages and plugins and building. That took another couple of minutes before it reported the app running. Then upon trying to connect to it from the browser:
=> App running at: http://localhost:3000/ I20160306-12:52:41.799(-8)? Exception from sub mochaServerRunEvents id hymWiYcTYEksBjYLi Error: Did not check() all arguments during publisher 'mochaServerRunEvents' I20160306-12:52:41.800(-8)? at [object Object]._.extend.throwUnlessAllArgumentsHaveBeenChecked (packages/check/match.js:429:1) I20160306-12:52:41.800(-8)? at Object.Match._failIfArgumentsAreNotAllChecked (packages/check/match.js:109:1) I20160306-12:52:41.800(-8)? at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1698:18) I20160306-12:52:41.800(-8)? at Subscription._runHandler (packages/ddp-server/livedata_server.js:1026:17) I20160306-12:52:41.800(-8)? at Session._startSubscription (packages/ddp-server/livedata_server.js:845:9) I20160306-12:52:41.800(-8)? at Session.sub (packages/ddp-server/livedata_server.js:617:12) I20160306-12:52:41.800(-8)? at packages/ddp-server/livedata_server.js:551:43 I20160306-12:52:42.666(-8)? MochaRunner.runServerTests: Starting server side tests with run id iCPEhQmJe6CYr34aW W20160306-12:52:42.668(-8)? (STDERR) MochaRunner.runServerTests: failures: 0 I20160306-12:52:42.677(-8)? Exception while invoking method 'mocha/runServerTests' Error: Did not check() all arguments during call to 'mocha/runServerTests' I20160306-12:52:42.677(-8)? at [object Object]._.extend.throwUnlessAllArgumentsHaveBeenChecked (packages/check/match.js:429:1) I20160306-12:52:42.678(-8)? at Object.Match._failIfArgumentsAreNotAllChecked (packages/check/match.js:109:1) I20160306-12:52:42.678(-8)? at maybeAuditArgumentChecks (packages/ddp-server/livedata_server.js:1698:18) I20160306-12:52:42.678(-8)? at packages/ddp-server/livedata_server.js:711:19 I20160306-12:52:42.678(-8)? at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1) I20160306-12:52:42.678(-8)? at packages/ddp-server/livedata_server.js:709:40 I20160306-12:52:42.678(-8)? at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1) I20160306-12:52:42.678(-8)? at packages/ddp-server/livedata_server.js:707:46 I20160306-12:52:42.679(-8)? at tryCallTwo (/Users/caedmon/.meteor/packages/promise/.0.5.2-beta.12.115c7uh++os+web.browser+web.cordova/npm/node_modules/meteor-promise/node_modules/promise/lib/core.js:45:5) I20160306-12:52:42.679(-8)? at doResolve (/Users/caedmon/.meteor/packages/promise/.0.5.2-beta.12.115c7uh++os+web.browser+web.cordova/npm/node_modules/meteor-promise/node_modules/promise/lib/core.js:171:13)
It appears meteor test isn’t compatible with audit-argument-checks. Removed the offending package and the test reporter shows up in the browser. Not finding or running my tests, but it’s a little closer to working.
Still seems like it takes way too long to start up.
If I add the winston npm package to meteor, and then simply write import winston from "winston";, then I got this error:
W20160308-20:05:41.563(1)? (STDERR) Error: ENOENT, no such file or directory '/node_modules/pkginfo/lib'
W20160308-20:05:41.564(1)? (STDERR) at Object.fs.readdirSync (fs.js:666:18)
W20160308-20:05:41.564(1)? (STDERR) at Function.pkginfo.find (node_modules/pkginfo/lib/pkginfo.js:95:1)
W20160308-20:05:41.564(1)? (STDERR) at Function.pkginfo.read (node_modules/pkginfo/lib/pkginfo.js:119:1)
W20160308-20:05:41.565(1)? (STDERR) at module.exports (node_modules/pkginfo/lib/pkginfo.js:69:1)
W20160308-20:05:41.565(1)? (STDERR) at meteorInstall.node_modules.pkginfo.lib.pkginfo.js (node_modules/pkginfo/lib/pkginfo.js:132:1)
W20160308-20:05:41.565(1)? (STDERR) at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:176:1)
W20160308-20:05:41.565(1)? (STDERR) at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:82:1)
W20160308-20:05:41.565(1)? (STDERR) at meteorInstall.node_modules.winston.lib.winston.js (node_modules/winston/lib/winston.js:14:1)
W20160308-20:05:41.565(1)? (STDERR) at fileEvaluate (packages/modules-runtime/.npm/package/node_modules/install/install.js:176:1)
W20160308-20:05:41.565(1)? (STDERR) at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:82:1)
It’s meteor 1.3 beta-12.
I’m only importing it on the server.
On the other hand, this works:
let winston = Npm.require('winston');
Like many others, I am tracking this thread for an update on the working Beta.16 release. I am eagerly awaiting the release so to not have to clone from head for the setup of a new project.
Please announce here - too many beta threads…
Edit
1.3-beta.16 just released and seems to work fine now. But the testing boilerplate has been removed?
Edit2
Take that back https://github.com/meteor/meteor/issues/6447
I’m rewriting my app from 1.2 blaze to 1.3 with react and I feel the lack of my DB performance there:
Meteor 1.2 Blaze, ~260 items in minimongo.
(Gif explanation: https://dl.dropboxusercontent.com/u/15382350/blaze4.gif)
1:
All time… 117ms.
DB insert … 32ms
2:
All time… 120ms.
DB insert … 32ms
Meteor 1.3.12, react, ~85 items in minimongo.
(Gif: https://dl.dropboxusercontent.com/u/15382350/react3.gif)
1:
All time… 372
DB insert … 204
2:
All time… 414
DB insert … 217
As a result I putted 300 dots on Blaze and it’s still ~120ms, when with react and 160 dots there it grows up to 300ms in DB insert and 500 overall …
DB insert from the client:
_setDot (e) {
e.preventDefault();
…
console.log(‘before insert’);
Comments.insert({…}, (e, r) => {
console.log(‘Insert callback’);
});
}
In both cases the same code in collections and identical packages: collection2, simple-schema, publish-composite, subs-manager. Meteor 1.3 imports system and file structure are based on draft of meteor guid and meteor module-todos-react (actually react structure and routing are copied from there). Okay, I can understand that there are should be some problems with unnecessary rerender in react, okay, but what could be with DB?
I’m frustrated. I’ve changed app structure twice, the last time copied it from meteor todos, I delete all unnecessary field from publish, I tried few times to optimize my react components. And it’s still worse then it was before. What to do? Wait for the 1.3 official release? Try mantra path? Forget about 1.3/imports/react and come back to 1.2 and blaze?
Edit Okay, I’ve fixed it, set the shouldComponentUpdate for mapped dots and now they do not rerender after each new placed dot. As a result, react render time ~50-60ms 
Component (re)rendering is a big gotcha in React.
This is a must-read:
Also, install the React performance tools and learn how to use them:
http://benchling.engineering/performance-engineering-with-react/
http://benchling.engineering/deep-dive-react-perf-debugging/
I just learned about it recently and it’s been invaluable!
4 Likes