Ever since summer '16 patch 10 or so my Lightning Out App has not been loading.

Checking the console output shows that the framework throws an exception like SyntaxError: JSON.parse: unexpected keyword at line 577 column 62 of the JSON data.

Seems like it's having trouble parsing the server's response to the request for the lightning component's metadata. Going to line 577 of column 62 shows that the line it is choking on is

"code":function(cmp, fn) { return !(cmp.get("v.convo.Record.ReadFlag__c")); },

which makes sense because that's not valid JSON, but the question is why the server is returning the code like that.

It works fine standalone (by going to https://{my domain}.my.salesforce.com/c/{myapp}.app) but fails when I use it in a Lightning Out component, or even as a Lightning Tab in LEX (will make another post for that).

I got no answers on the developer forums, so hoping that someone can help me out here.

Here is a larger snippet of the XHR

update : So I have attempted to recreate the issue in a sandbox org post-summer'16 and a dev org pre-summer'16, and I cannot recreate the issue, but I have noticed one major difference.

In the problematic org, the entire app seems to be defined in a single XHR request with the name of the Lightning App ("c/MyLightningApp.app?aura.format=JSON&aura.formatAdapter=LIGHTNING_OUT"), with the components being defined in a "componentDefs" parameter.

In the test dev org and the sandbox org, the "componentDefs" parameter defining all of the lightning components does NOT exist in the XHR request, but instead is defined much differently in an "app.js" script, which does not exist in the problematic org.

The way the components are defined is different as well, in the problematic org, the Conversation lightning component is defined like

            "code":".cConversation#noround {border-radius:0}",

in the sandbox and test org,

$A.componentService.addComponentClass("markup://c:Conversation",function() {
var c$Conversation = {

I may be missing something here, but that is what I noticed while digging through the console..

  • I would suggest raising the case with Salesforce, as it seems as internal Salesforce issue.
    – vladykx
    Jul 14, 2016 at 1:07
  • @vladykx : I can't submit tickets for development, it forces me to go to the developer forums..
    – Jason Lee
    Jul 14, 2016 at 5:19
  • @DougChasman Can you please take a look here?
    – SE_User
    Jul 14, 2016 at 5:51

1 Answer 1


OK - reading through this its not Lightning Out related since you are able to repro this with a Lightning Component Tab in LEX which does not leverage LO. Also, LO does not change app.js, app.css etc in any way and is not involved in the generation of Aura Framework resources. The difference is the way the metadata is being packaged and delivered is because of the difference between how the framework handles statically visible versus dynamic dependencies. LC Tabs are always dynamic dependencies and LO will be dynamic unless you explicitly add an aura:dependency to your LO dependency app - that is what its there for and you should be seeing a warning to add this for any missing dependency(s) in the javascript console in the LO scenario.

At least for the LO scenario if you add an <aura:dependency resource="c:Conversation"/> things should switch to static dependency handling and the problem should then go away. I am certain we could reproduce this in a standalone .app outside of LO and LC Tabs if you switched to using $A.createComponent().

As for the why its happening in one org and not the other I am not sure what is going on yet. This is definitely bizarre looking (truncated code for starters): enter image description here

For clarity would you mind changing the title of this post to not be LO specific? Dependency handling and metadata management is owned by the core Aura Framework team (I just made them aware of it) but given the title of this post I expect they did not read far enough into it to realize its a general dynamic dependency issue.

  • Changing the visualforce page to use namespace:container instead of c:container, and including a catch-all dependency like<aura:dependency resource="namespace:*" /> seems to have fixed it as far as I can see.. So the issue was with dynamic dependencies?
    – Jason Lee
    Jul 29, 2016 at 17:11
  • When you use the dependency tag you are telling (forcing) the framework to include that dependency (and all its intrinsic dependencies) as part of the component dependencies itself. So if in cmp A you add dependency B, whenever you request A you will get B (regardless of when is invoked). The same applies for the application (you call it static) The content of app.js will be all the dependencies that we can spider from the application itself (the root). The rest is consider dynamic (we always do a diffing with what you already have in app.js). Not sure if that answers the question?
    – Diego
    Jul 31, 2016 at 23:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .