I’m using the “promesa” lib on node.js (in an AWS lambda) and seeing an error that suggests that the release compile is obfuscating a promesa fn when it shouldn’t. Anyone seen this before or have an example of promesa being advanced compiled with shadow?

2018-08-04T02:57:14.739Z	15b1728f-9792-11e8-bf66-b982ac270145	TypeError: this.Rd is not a function
at Promise.f.promesa$protocols$IPromise$_catch$arity$2 (/var/task/handlers.js:680:71)
at zz (/var/task/handlers.js:676:641)
at Kz (/var/task/handlers.js:682:442)
at Fo (/var/task/handlers.js:778:164)

I just read the docs on https://shadow-cljs.github.io/docs/UsersGuide.html#_simplified_externs. I’ll see if that can fix the problem

@steveb8n turn on :compiler-options {:infer-externs :auto} if you haven't. run shadow-cljs release your-build --pseudo-names to figure out what .Rd is.

@thheller: thanks! Glad to hear there is hope! 😃 Tried it now, using import * as shadowBrowser from '../lib/shadow.cljs.devtools.client.browser', as the first clsj import being done, but it doesn’t fix the problem. Worse, it makes the release build fail. What am I not understanding correctly?

well yeah thats the problem. the file only exists in dev builds and you must conditionally require it

but you can't do conditional requires with import

typically you would if (process.env.NODE_ENV == "development") { require("../lib/shadow.cljs.devtools.client.browser"); }

you can maybe do this after all the imports though

don't know how other tools deal with import and require in the same file

are you actually running in the browser though? not exactly sure how vscode works internally. maybe its a node environment?

I think it is a node environment. 😀

which error do you get though?

it should at least print something in the console?

The error message when the release build fails?

no dev stuff

you should get some kind of message when the devtools either fail to load or connect

Ok, not at the computer right now, but will check ASAP. Should I be using the browser client, even though it is a node environment?

probably no but isn't it based on electron? which is this weird hybrid

Yes, Electron.

No, I can’t find any output from the devtools anywhere.

check the generated lib/cljs_env.js file please

the CLOSURE_DEFINES in particular?

is the code available somewhere? I can take a look at it later

CLOSURE_DEFINES:

var CLOSURE_DEFINES = $CLJS.CLOSURE_DEFINES = {"shadow.cljs.devtools.client.env.repl_pprint":false,"shadow.cljs.devtools.client.env.devtools_url":"","shadow.cljs.devtools.client.env.autoload":false,"shadow.cljs.devtools.client.env.proc_id":"2cce7108-2ff9-43b0-9469-40d5785b5f80","goog.ENABLE_DEBUG_LOADER":false,"shadow.cljs.devtools.client.env.server_port":9631,"shadow.cljs.devtools.client.env.use_document_host":false,"shadow.cljs.devtools.client.env.module_format":"js","goog.LOCALE":"en","shadow.cljs.devtools.client.env.build_id":"calva","shadow.cljs.devtools.client.env.ignore_warnings":false,"goog.DEBUG":true,"shadow.cljs.devtools.client.env.ssl":false,"shadow.cljs.devtools.client.env.enabled":true,"shadow.cljs.devtools.client.env.server_host":"localhost","goog.TRANSPILE":"never"};

"shadow.cljs.devtools.client.env.enabled":true

so when the shadow.cljs.devtools.client.browser is loaded it should defiinitely do something

Maybe the TypeScript compiler optimizes it away?

try just import "./lib/...."

Checked it. It didn’t optimize it away. Now will try with just import

there is one suspicious thing: the 9631 port

which means you probably have 2 shadow-cljs isntances running?

might not be intentional and you are just connected to the wrong one?

I do have two instances running. The project I am testing my extesion with and then the watcher building the library/modules. I do not think I am connected to the wrong one.

I get SyntaxError: Unexpected token import when just importing. At runtime, the TS compiler seems to think it is dandy.

did you try require instead yet?

I was talking shit. Had placed the import in the generated file…

The TS compiler rewrites it as require. (Yes, I did try the conditional require. It helps building the release build, but still this connection problem.)

But now using import (transcribed to require) I do get an error message with a hint, at last…

window not defined here: window.addEventListener("beforeunload",(function (){ …

so I guess its really node then

try adding :runtime :node in your build config

and loading ...client.node instead of .browser

Thanks! Will try right away.

Now it connected! But running into a new problems

ReferenceError: SHADOW_NODE_EVAL is not defined
	at Object.shadow$cljs$devtools$client$node$node_eval [as node_eval] (/Users/pez/Projects/clojure4vscode/lib/shadow.cljs.devtools.client.node.js:62:14)

Line 62: var result = SHADOW_NODE_EVAL(js,source_map_json);

ugh

I placed :runtime :node in the target config, was that correct?

yes. hmm sorry the .node stuff is not currently compatible with :npm-module

I'll see about fixing that

it currently assumes :node-libray or :node-script

I get very confused by the fact that I am using Calva for developing Calva. For Calva I use the built Calva extension, so maybe I need to build that and install before we conclude that things does not work…

No, I get the same error.

I’ll package a release w/o the :runtime :node config for now. Do you think I can fix it in shadow-cljs and send you a PR, or is it expert level stuff?

hmm I just checked the code and it should actually work

ah no wait nevermind.

I guess you can try and set global.SHADOW_NODE_EVAL = function(js, sm) { goog.globalEval(js); } before you load the .node ns

ah no wait the goog. won't exist yet

so try just global.SHADOW_NODE_EVAL = function(js, sm) { eval(js); }

the problem itself isn't hard to fix

the problem is identifying the platform correctly and then doing things in the correct order

I don't know how the vscode or electron stuff executes exactly

global.SHADOW_NODE_EVAL = function(js, smJson) {
  if (smJson) {
    js += "\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,";
    js += Buffer.from(smJson).toString('base64');
  }

  // console.log(js);

  return VM.runInThisContext.call(global, js,
    {filename: "<eval>",
     lineOffset: 0,
     displayErrors: true});
};

you can also try just adding that. thats the default fn used by :node-script and :node-library

VM is var VM = require("vm");

Now a new error:

ReferenceError: cljs is not defined
	at <eval>:2:1
	at <eval>:3:1078
	at ContextifyScript.Script.runInThisContext (vm.js:23:33)
	at runInThisContext (vm.js:95:38)
	at global.SHADOW_NODE_EVAL (/Users/pez/Projects/clojure4vscode/out/calva/extension.js:14:32)
	at Object.shadow$cljs$devtools$client$node$node_eval [as node_eval] (/Users/pez/Projects/clojure4vscode/lib/shadow.cljs.devtools.client.node.js:62:14)

hmm yeah thought so. the VM part doesn't work

try with direct eval instead

This should all go in the development conditional, right? (Not that I have gotten that one to work yet, but anyway.)

yes

I need to go now. Will be back later today. Can’t express how much I appreciate all your help.

Curious, the SHADOW_EVAL function is called with the cljs code compiled to js as a result of nrepl carrying out the eval operation?

its used to to eval the code created by the repl yes

Using eval directly gives the same error.

hmm yeah the module isolation is tricky with this one

do you know if the TS tools do something to the compiled CLJS code at all?

or does it just copy the files along with its output?

The TS compiler never touches the CLJS generated code, I’m pretty sure.

hm, what's the flow to recompile individual files with the node-repl? Especially when e.g. I'm building a library, so don't really have an entry point that requires all the files I might want to load in the node-repl to try out

What I do is to build the cljs code toward a ‘/lib’ directory which is also symlinked to the /out directory where the TS compiler puts it stuff. Conceptually like so:

/out/calva/*.js (generated from *.ts)
/out/lib/*.js (generated from *.cljs)

I do the copying.

@alex340 the common workflow is to load your code via load-file or (require 'that.ns :reload). Cursive has a keybind to load the current file in the REPL and thats what I use all the time. The command uses load-file but require also works.

I tried (require 'some.ns :reload), but that didn't seem to cause shadow-cljs to rebuild it

hmm it should?

Rebuilds are not triggered by that, AFAIK, @alex340.

the file has an explicit typo in it, and yet

cljs.user=> (require 'verktyg.styled :reload)
nil

ok, so how are they triggered when using a repl-based flow?

Are you running a watcher on the code?

no, because I don't have any particular entry point

it's just a collection of namespaces as part of a library

they ARE supposed to be triggered by that. there does not need to be a watcher running for that.

if its not thats a bug

totally possible, not ruling that out. if you can reproduce it in a dummy project please report it

I can push this project. it's a bit of a mess, so didn't want to publish it yet, but w/e

or actually, maybe I can set a simpler dummy

I can try myself in a bit. need to finish this post first. 😉

@thheller https://github.com/bwalex/shadow-cljs-reload-bug

the package.json is a bit lazy, in that it contains irrelevant stuff (and so does the shadow-cljs.edn), but that's about it

thx. will check it out.

@thheller: what is the :runtime config supposed to do? (I don’t find it mentioned in the docs.)

decide which REPL client gets compiled

https://clojureverse.org/t/faster-startup-via-aot/2603

@lilactown should maybe help with your CI issues

@thheller: that should mean that I can keep that part of the config even though it is not solving my problem right now, because when Calva is used “out there” it will be the REPL client of the particular projects that are in play and not the REPL client in the Calva extension?

Sorry if it is a stupid question, I meant what I said that using Calva for Calva development confuses me. 😃

yes, user projects won't be affected

its just your REPL while developing the calva for calva inception stuff 😛

Haha, thanks. I’ll try to remember that.

anyone using antd with shadow?