Reflect.getOwnMetadata - Updating Aurelia - aurelia

Reflect.getOwnMetadata is not a function in karma with latest Aurelia
I believe my issue to be the same as this, but I am unsure. I needed to update 'binding' from aurelia-binding#^1.0.0-beta.1.0.5 to aurelia-binding#^1.0.0-beta.1.3.0, due to a bug fix within that release, since updating I recieve the following error:
Uncaught (in promise) Error: TypeError: Reflect.getOwnMetadata is not
a function(…)
After a bit of research, mostly being linked back to the question above in one way or another, I had hoped their solution would solve mine however, gulp watch returns: import 'aurelia...' unexpected reserved work. Unsure what I am missing
I think the actual issue is with loading the following, seems to break here first
(function(System, SystemJS, require) {define(["npm:aurelia-templating-resources#1.0.0-beta.1.0.2/aurelia-templating-resources"], function(main) {
return main;
});
})(System, System);

Related

Error: An error was thrown when attempting to render log messages via LogBox

I'm working on an app and everything is working fine, then I began to get this error when I log things out from try-catch block
Error: An error was thrown when attempting to render log messages via LogBox.
Please what could cause this?
i had the same issue and i spend all most two days to find any solution and in the end i find their is one console.log() statement which is logging the entire redux store, so as soon as i removed the console statement error removed.

Syntax error handling in dojo 18n resource file

require(["dojo/i18n!myapp/nls/extTools_i18nStrings"],function(extTools_i18nStrings){
// Do something with the loaded file
});
If the resource file (extTools_i18nStrings) has syntax error, it will be shown in dojo.js. How can I handle it in my code?
Try catch block did not work.
Thanks in advance.
Error: Script error .............dojo.js:15
The quick answer is you don't want to. The right thing to do is fix the bundle. This is the same as having errors in your application code, and you would not expect the code to 'handle' that.
But since i18n is an AMD plugin running as part of the loader (which is why you can't try/catch it), the error might be reported through the AMD micro event API, and you could use that to show a better error. I'm not sure how you 'handle' this syntax error other than showing an error.
If you can't control the quality of the bundles via some part of your development or build process you'd have to invent your own alternative to dojo/i18n and you probably don't want to go down that route for all of your bundles.

Ember-data 1.0.0-beta.19: store.find() returns DS.INTERNALMODEL instances

I have update Ember-data to 1.0.0-beta.19 and now store.find('events') resolved promise returns DS.INTERNALMODEL instances, instead of DS.MODEL. With Ember-data 1.0.0-beta.18 it was working fine. Any ideas?
UPDATE
At the end i found out that somewhere in my app code i was using Ember-data internal code like store.find('events.content'), causing an exception. The debugger was not so helpful tracing it, but removing this fixed my issue.
This is a bug, if the promise resolves with DS.InternalModel, those are only for internal use of Ember-Data and shouldn't be exposed to user code. Please file a bug if this is still a problem
This is on purpose. It's noted in the chanelog:
#3094 Lazily materialize DS.Models for app code, use InternalModel inside ED otherwise
It should work largely with no issues. Are you having issues with it?
You can access the DS.Model using InternalModel.record

undefined local variable or method `start_test_server_in_background' for #<Object:0x007ffc49a5e130>

This has been asked before for .12.0 but I am now getting a similar error in .14.2 .
Up until a few weeks ago I was running calabash.framework 11.4 because it worked, was stable, and it was under lock and key on our development server. We went through a recent state of updating all of our gems and services and while our build server still functions calabash is no longer recognizing the "start_server_in_background" method. I am at a loss on how to remedy this. I tried a complete wipe and reinstall on my local mirror to no avail, and am considering rolling everything back to the previous working versions. However I would like to solve this to keep everything up to date.
I have tried the following solutions with no success.
undefined local variable or method `start_test_server_in_background' for main:Object
https://github.com/calabash/calabash-ios/issues/669
https://github.com/calabash/calabash-android/issues/371
This is my error after the scenario runs
undefined local variable or method `start_test_server_in_background' for #<Object:0x007f9a7c07ba48> (NameError)
/Users/mycomp/.rvm/gems/ruby-2.2.1#global/gems/rspec-expectations-3.2.1/lib/rspec/matchers.rb:926:in `method_missing'
/Users/mycomp/KonyiOSWorkspace/user/Kony/iOS-6.0.3.GA_v201503250510/VMAppWithKonylib/features/mobile/helpers/ios/support/app_life_cycle_hooks.rb:44:in `Before'
The recommend way of launching the application is to use:
options = { }
launcher.relaunch(options)
launcher.calabash_notify(self)
In your support/env.rb file you need to:
require 'calabash-cucumber/cucumber'
not calabash-cucumber.

Dojo console error objects empty

All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.