React-sketchapp: GraphQL example won't run due to use of 'const' on El Capitan and lower

[theprogramme]

I am reporting an issue in the GraphQL example. After npm run render an error occurs in relation to the use of const, apparently due to "strict mode".
Disclaimer: I'm a long way on the design side of the design-dev fence - apologies if this is trivial.

Expected behavior:
A sketch document rendered with live data from a GraphQL API.

Observed behavior:
npm run render
> profile-cards-gql@ render /Users/christianv/Projects/react-sketchapp/examples/profile-cards-graphql
> skpm build --watch --run

🖨 Copied src/manifest.json in 6ms SyntaxError: Unexpected keyword 'const'. Const declarations are not supported in strict mode.. Plugin “react-sketchapp: Profile Cards w/ GraphQL”, line 6835: » const SuperInit = (0, _runtime.SuperCall)(NSStringFromSelector("init"), [], { type: "@" });

How to reproduce:
Simply running npm run render after npm install

Sketch version:
43.2 (although irrelevant to this issue)

[ljharb]

What version of node? You'd need 6+ to be able to use const unconditionally.

[theprogramme]

v6.1.0

[s4908]

I am facing the same problem. node v7.10.0

[mathieudutour]

it's more about the macOS version than the node version. The plugin runs in JavaScriptCore and not Nodejs

[ljharb]

ahhh, mac-os-jsc is pretty far behind. We should be using babel and transpiling to ES5 then, just in case.

[mathieudutour]

skpm does transpile to ES5, it must be a dependency. We can add a custom .babelrc tho

[ljharb]

oh no, definitely never transpile node_modules, nope_octopus.gif.

If it's a dep, let's file a bug upstream :-)

[jongold]

I think the upstream bug is still in cocoascript-class (via sketch-polyfill-fetch via skpm) - there's an open PR to fix it. @darknoon can we get this merged pls 🙏

https://github.com/darknoon/cocoascript-class/pull/1

[darknoon]

@jongold I'm not trying to be an ass by not transpiling the code; it's just that ...args transpiles into arguments which doesn't work in cocoascript. So cocoascript-class requires a more recent version of JavascriptCore / macOS. I think the alternative was pretty hacky, but just curious why @theprogramme is running an old version of macOS…

[mathieudutour]

function test () {
  log(arguments[0])
}

test('a')

works fine. Am I missing something?

[darknoon]

@mathieudutour here is how it's used for being able to call super: https://github.com/darknoon/cocoascript-class/blob/006abf0c4c95604df36c83135d07dddd7ad64595/src/runtime.js#L4

[mathieudutour]

yeah but I just tried using arguments in the plugin sandbox and it worked fine

[darknoon]

@mathieudutour yeah I tried to do the same thing; all I remember is that it stopped working, so feel free to try it out and remind us what the real issue was :D

[theprogramme]

I'm running an old MacOS because they dropped support for the (insecure) PPTP VPN protocol which I needed to access a client network.

If that's the cause of this issue, I'll update. Thanks :)

On 9 Aug 2017, at 3:55 am, Andrew Pouliot [e-mail] wrote:

@jongold I'm not trying to be an ass by not transpiling the code; it's just that ...args transpiles into arguments which doesn't work in cocoascript. So cocoascript-class requires a more recent version of JavascriptCore / macOS. I think the alternative was pretty hacky, but just curious why @theprogramme is running an old version of macOS…

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[kannonboy]

@mathieudutour @darknoon I'm late to the party :) but I've just hit the same problem with El Capitan users of JIRA Cloud for Sketch. I don't think the problem is with arguments per se, but rather with the way Babel transforms the spread operator for arrays.

Babel reasonably assumes the func on https://github.com/darknoon/cocoascript-class/blob/006abf0c4c95604df36c83135d07dddd7ad64595/src/runtime.js#L7 is a normal JavaScript function, and transpiles it into some ES5 that calls func.apply(), which is undefined since it's actually an MOBridgeSupportFunction, not a JS function.

To support earlier JavaScriptCore versions, we may have to write a more CocoaScript-friendly transform, or avoid using the spread operator -- (MochaJsDelegate's use of eval() makes a lot more sense to me now. :)

[mathieudutour]

Oh interesting!

I'm not sure what would be a CocoaScript friendly transform. The use of eval also makes sense, it's just unfortunate that it completely makes it impossible to optimise the code for the JIT optimiser :/

_(sorry for the close/re-opened, misclicked)_

[kannonboy]

We kicked around the problem at work, and the best we could come up with was eval() or codegening a giant switch statement, e.g.

switch (arguments.length) {
  case 0:
    return func()    
  case 1:
    return func(arguments[0]) 
  case 2:
    return func(arguments[0], arguments[1])
  ...

with some large number of cases. Neither seem particularly appealing :)