Fork me on GitHub
#shadow-cljs
<
2018-11-30
>
richiardiandrea00:11:37

I can only confirm that, even folks that haven't tried shadow 😃

❤️ 8
vigilancetech01:11:12

@thheller I did npm i shadow-cljs -g and it gave me that version I pasted above, but its still giving me release snapshots on the console. How do I tell what version of shadow is actually executing? I don't see any -version option

lilactown01:11:53

@vigilancetech you also should install shadow-cljs as a dependency in your application's project. the shadow-cljs command will use whatever version of it is installed in your project

vigilancetech02:11:10

@lilactown hmm... my project dependency file doesn't have any dep for shadow. Wouldn't it automatically be using the newest installed then?

lilactown02:11:02

You should install it locally in your projects package. Json

thheller08:11:27

@vigilancetech yeah I absolutely recommend installing shadow-cljs in your project. easier to ensure you get the correct version

thheller08:11:34

the global install you don't really need.

pez09:11:35

I need some advice. For two of the Calva extensions to VS Code I have a shadow-cljs based tool-chain, where TypeScript is used to create the extension entry point and shadow-cljs is used to compile the ClojureScript code into a JavaScript library that the TypeScript code then consumes. For when the extensions need to share logic I have so far relied on them exposing API:s to each other. But this creates a dependency between them that I rather not want to have. So I am leaning towards creating a lib that is published in a way that all my extensions can use. The options I see are either to build a CLJS library that I can put on clojars, or a JS library that I publish as an NPM module. Do I have other options that I don't see? (I think that a CLJS library makes the most sense, but am not fully clear about what my tradeoffs are.)

thheller09:11:05

not sure what you mean. typescript can't consume clojars?

pez09:11:41

No, it would be the CLJS that consumed that.

thheller09:11:51

but how does it all work together in the end?

thheller09:11:18

if you have 3 different builds then you'll have 3 different cljs.core versions

thheller09:11:25

that are each not compatible with each other

pez09:11:41

Not sure I am following…

thheller09:11:47

so when they talk to each other you always have to serialize the data

thheller09:11:14

I don't quite understand why you have different extensions and how they interact with each other

thheller09:11:21

do they interact at all?

thheller09:11:34

and how is typescript involved in any of it?

pez09:11:33

TypeScript is what I use to integrate into VS Code. (I have changed this quite a few times, but the only thing that really worked for me was this setup.)

pez09:11:58

They are different extensions because they solve different enough problems, so someone can use some other REPL extension and still use Calva Formatter (for instance).

pez09:11:30

I also have a third extension, Calva Paredit, that is still TypeScript only, but that I am going to change to the same toolchain so that I can use some of functions that I have developed for the formatter.

thheller09:11:43

so with CLJS you want to avoid splitting things as much as possible

thheller09:11:03

since the whole idea of whole-program-optimizations breaks pretty badly if you don't have the whole program

thheller09:11:17

so what I would probably do is create a "calva-core" library

pez09:11:21

Yes, one CLJS lib for all Calva common things.

thheller09:11:28

that contains everything you want

thheller09:11:47

and then have the typescript parts expose the parts you want to vscode

thheller09:11:00

but only have one CLJS build for everything

thheller09:11:13

could be using :npm-module

thheller09:11:03

or :node-library depending on how many exposed API's you actually need

pez09:11:03

Ah, but I never got the :npm-module working last time I tried it. So went back to :node-library even though the API is pretty thick.

pez09:11:28

Why is one-lib preferable over each extension having its own CLJS lib that each are using a common lib?

thheller09:11:09

when you compile clojurescript it always implicitely contains cljs.core

thheller09:11:27

so if you have 3 separate libs you have 3 separate cljs.core "instances"

thheller09:11:42

which means that map instances from plugin-A cannot be accessed by B+C directly

thheller09:11:58

since they are different types

pez09:11:24

I see. Good that I asked about this!

pez09:11:51

But, sorry if I am a bit thickheaded, I use libraries from Clojars all the time, and have never seen this problem. Aren't they compiled into my code just like any other code?

thheller10:11:17

builds not libraries

thheller10:11:30

libraries are uncompiled .cljs files

thheller10:11:37

builds are compiled .js files

thheller10:11:41

important distinction

thheller10:11:56

BUILDS can't talk to each other easily

pez10:11:59

The extensions do not need to talk to each other, really.

pez10:11:12

I only need them to be able to share some code.

thheller10:11:43

I just published a demo repo showing what I would probably do

thheller10:11:22

npm i @shadow-cljs/npm-module-demo then require("@shadow-cljs/npm-module-demo")

thheller10:11:52

require("@shadow-cljs/npm-module-demo").hello("x")

thheller10:11:06

same as require("@shadow-cljs/npm-module-demo/foo.bar").hello("x")

thheller10:11:20

require("@shadow-cljs/npm-module-demo/foo.baz").hello("x") to access the other ns

thheller10:11:08

doesn't need to be a scoped package. just didn't want to create another "global" dummy package on npm

thheller10:11:20

so say you publish calva-core to npm that way

thheller10:11:02

the typescript code can then just require("calva-core/foo.bar") so get access to whatever CLJS fn it needs

thheller10:11:17

BUT this important bit here is that you only have one compiled CLJS version

thheller10:11:02

of course that is totally optional but with 3 different extensions that means cljs.core will only be loaded once

thheller10:11:15

reducing memory and load time and stuff

thheller10:11:25

and the 3 extensions can actually talk to each other if needed

thheller10:11:44

that might not make sense at all

thheller10:11:02

still don't understand what role the typescript plays in all of this of how much of the code you actually share

pez10:11:41

Thanks a lot! I'll have a look at this and see where it takes me.

pez10:11:56

Will the CLJS code have as easy access to the functions in this module as well? Seems like it will publish a JS API. Which is not too much of a bother, I am mainly curious.

thheller10:11:39

the CLJS in calva-core can talk to any other CLJS in calva-core but not to any other CLJS not in calva-core

pez10:11:21

I will need to play with it to get it. Super duper help, thanks again.

thheller11:11:31

the only thing to remember really is your builds. a CLJS build can only consume uncompiled CLJS code, it can never consume compiled CLJS code (macros would not work)

thheller11:11:47

so if you want 3 separate CLJS builds than putting a uncompiled CLJS library on clojars is your only option

thheller11:11:33

if you however have 3 separate typescript builds then putting one compiled CLJS build on npm is fine

pez11:11:54

I currently have three separate TS builds and two separate CLJS builds, but I'm willing to try something else. 😃

thheller11:11:23

I would probably get rid of the TS completely but if that is important to you it should be fine

pez12:11:58

It is only important to me because it was the only way I could get my development process work.

achikin12:11:53

@thheller do you support :warnings under :compiler-options?

thheller13:11:16

@achikin I'm not actually sure. I'd think so?

thheller13:11:34

hmm no I guess I don't. do you need it? never came up before

achikin14:11:59

Not that much. I have some deprecation warnings that annoy me a bit.

achikin14:11:36

2. Unhandled clojure.lang.Compiler$CompilerException
   Error compiling shadow/build/compiler.clj at (455:13)
1. Caused by java.lang.RuntimeException
   Unable to resolve var: comp/*source-map-data-gen-col* in this context

achikin14:11:02

I'm trying to run shadow-cljs from within cider.

thheller14:11:03

wrong CLJS version

thheller14:11:19

shadow-cljs 2.7.x requires CLJS 1.10.439+

achikin14:11:29

That was my first guess, so I've removed cljs dependency from project.clj

thheller14:11:31

you are using an older CLJS version probably

thheller14:11:43

don't do that when using project.clj

thheller14:11:02

its undefined which cljs version you'll get then

thheller14:11:13

since it'll pick the first one encountered. not the latest one.

achikin14:11:29

Thank you, I'll introduce it back.

thheller14:11:09

or don't use project.clj. the problem is taken care of in shadow-cljs.edn 😉

achikin15:11:40

I have quite big server-side project.clj 😞

achikin15:11:47

Show: Project-Only All 
  Hide: Clojure Java REPL Tooling Duplicates  (23 frames hidden)

1. Unhandled clojure.lang.ExceptionInfo
   missing instance
   {}

                  core.clj: 4739  clojure.core/ex-info
                  core.clj: 4739  clojure.core/ex-info
               runtime.clj:   11  shadow.cljs.devtools.server.runtime/get-instance!
               runtime.clj:    8  shadow.cljs.devtools.server.runtime/get-instance!
                   api.clj:  130  shadow.cljs.devtools.api/worker-running?
                   api.clj:  128  shadow.cljs.devtools.api/worker-running?
                   api.clj:  207  shadow.cljs.devtools.api/watch
                   api.clj:  201  shadow.cljs.devtools.api/watch
                   api.clj:  205  shadow.cljs.devtools.api/watch
                   api.clj:  201  shadow.cljs.devtools.api/watch
                      REPL:    1  user/eval55989
                      REPL:    1  user/eval55989
             Compiler.java: 7062  clojure.lang.Compiler/eval
             Compiler.java: 7051  clojure.lang.Compiler/eval
             Compiler.java: 7025  clojure.lang.Compiler/eval
                  core.clj: 3206  clojure.core/eval
                  core.clj: 3202  clojure.core/eval
                  main.clj:  243  clojure.main/repl/read-eval-print/fn
                  main.clj:  243  clojure.main/repl/read-eval-print
                  main.clj:  261  clojure.main/repl/fn
                  main.clj:  261  clojure.main/repl
                  main.clj:  177  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  657  clojure.core/apply
                  core.clj:  652  clojure.core/apply
                regrow.clj:   18  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  657  clojure.core/apply
                  core.clj: 1965  clojure.core/with-bindings*
                  core.clj: 1965  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   85  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   55  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  222  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
    interruptible_eval.clj:  190  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
                  AFn.java:   22  clojure.lang.AFn/run
   ThreadPoolExecutor.java: 1142  java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  617  java.util.concurrent.ThreadPoolExecutor$Worker/run
               Thread.java:  745  java.lang.Thread/run

achikin15:11:03

For some reason I can't connect from emacs

achikin15:11:22

I'm running shadow-cljs server separately, but still no luck

thheller15:11:16

shadow-cljs server starts its own instance with its own nrepl server

thheller15:11:30

but the above error suggests that you are not connected to that

thheller15:11:48

but instead some other JVM running an nrepl server (that happens to have the shadow-cljs dependency loaded)

thheller15:11:16

you can use the embedded version https://shadow-cljs.github.io/docs/UsersGuide.html#embedded if you prefer running shadow-cljs inside your other JVM

thheller15:11:27

then you don't need the separate shadow-cljs server instance

thheller15:11:33

FWIW it doesn't matter how large your server-side is. it is perfectly fine to use project.clj for the server-side and shadow-cljs.edn for the CLJS side of things

thheller15:11:52

but yeah tooling like emacs makes that pretty annoying

thheller15:11:10

so you probably want to be using the embedded version instead

achikin15:11:40

Doh. I'll probably make some PRs both to cider and shadow docs after the weekend 🙂

👍 4
thheller15:11:47

I don't use emacs and the setup seems to be changing somewhat regularly. so the instructions somehow constantly change and its impossible for me to keep up.

thheller15:11:03

I can't get it working at all anymore 😛

achikin15:11:39

Me either 😞

achikin15:11:52

1. Unhandled java.lang.IllegalStateException
   Can't change/establish root binding of: *nrepl-cljs* with set

                  Var.java:  223  clojure.lang.Var/set
                   api.clj:  361  shadow.cljs.devtools.api/nrepl-select
                   api.clj:  356  shadow.cljs.devtools.api/nrepl-select
                   api.clj:  358  shadow.cljs.devtools.api/nrepl-select
                   api.clj:  356  shadow.cljs.devtools.api/nrepl-select
                      REPL:    1  user/eval73496
                      REPL:    1  user/eval73496
             Compiler.java: 7062  clojure.lang.Compiler/eval
             Compiler.java: 7052  clojure.lang.Compiler/eval
             Compiler.java: 7025  clojure.lang.Compiler/eval
                  core.clj: 3206  clojure.core/eval
                  core.clj: 3202  clojure.core/eval
                  main.clj:  243  clojure.main/repl/read-eval-print/fn
                  main.clj:  243  clojure.main/repl/read-eval-print
                  main.clj:  261  clojure.main/repl/fn
                  main.clj:  261  clojure.main/repl
                  main.clj:  177  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  657  clojure.core/apply
                  core.clj:  652  clojure.core/apply
                regrow.clj:   18  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  657  clojure.core/apply
                  core.clj: 1965  clojure.core/with-bindings*

thheller15:11:36

this means that the nrepl middleware is not used

vigilancetech16:11:47

ok, I've installed shadow 2.7.6 both globally, in my project directory, in the devDependencies in package.json, and as a dependency of my project in shadow-cljs.edn and THIS is what I get when I start the server in the project directory: shadow-cljs - config: /home/kevin/0work/guardian-dashboard/shadow-cljs.edn cli version: 2.3.24 node: v8.12.0 Why? Is there a cache somewhere I need to clean out first?

vigilancetech17:11:00

doing a global grep of my project folder shows no file contains "2.3.24" anymore

thheller17:11:53

@vigilancetech what are ytou using to start? lein or deps.edn? probably not just shadow-cljs.edn right?

thheller17:11:33

what does /home/kevin/0work/guardian-dashboard/node_modules/shadow-cljs/package.json say?

vigilancetech17:11:12

oh, sorry, I was wrong about nothing saying "2.3.24". I was using grep from within emacs and it just was very slow in returning results. I must have been swap bound. There are a lot of instances of that in that file under node_modules. No, I'm just using shadow cli version with the shadow-cljs.edn file

thheller17:11:06

the only file of interest to me is the one above

thheller17:11:25

> There are a lot of instances of that in that file under node_modules.

thheller17:11:29

no clue what that means

vigilancetech17:11:36

{
  "_from": "[email protected]",
  "_id": "[email protected]",
  "_inBundle": false,
  "_integrity": "sha512-jmk9e9/8KbJOQI16Ww9bC8R3uleZFm1wvFKrnmYVFQrmB8opnVMeo5Z5HlNLo38rV9gpmyk797ayeeFRUH+lkA==",
  "_location": "/shadow-cljs",
  "_phantomChildren": {},
  "_requested": {
    "type": "version",
    "registry": true,
    "raw": "[email protected]",
    "name": "shadow-cljs",
    "escapedName": "shadow-cljs",
    "rawSpec": "2.3.24",
    "saveSpec": null,
    "fetchSpec": "2.3.24"
  },
  "_requiredBy": [
    "#DEV:/",
    "#USER"
  ],
  "_resolved": "",
  "_shasum": "44249c7dc6e0c7f4b77f547005a03772424a744e",
  "_spec": "[email protected]",
  "_where": "/home/kevin/0work/guardian-dashboard",
  "author": {
    "name": "Thomas Heller"
  },
  "bin": {
    "shadow-cljs": "./cli/runner.js"
  },
  "bugs": {
    "url": ""
  },
  "bundleDependencies": false,
  "dependencies": {
    "babel-core": "^6.26.0",
    "babel-preset-env": "^1.6.0",
    "mkdirp": "^0.5.1",
    "node-libs-browser": "^2.0.0",
    "readline-sync": "^1.4.7",
    "shadow-cljs-jar": "1.1.2",
    "signal-exit": "^3.0.2",
    "source-map-support": "^0.4.15",
    "ws": "^3.0.0"
  },
  "deprecated": false,
  "description": "ClojureScript compiler and JS bundler",
  "disabled-scripts": {
    "install": "node ./cli/runner.js aot"
  },
  "engines": {
    "node": ">=6.0.0"
  },
  "homepage": "",
  "jar-version": "2.3.24",
  "keywords": [
    "clojurescript",
    "cljs"
  ],
  "license": "ISC",
  "name": "shadow-cljs",
  "repository": {
    "type": "git",
    "url": "git+"
  },
  "version": "2.3.24"
}

thheller17:11:06

> "version": "2.3.24"

thheller17:11:18

clearly says which version is being used?

vigilancetech17:11:18

yes, right, but I did the npm i shadow-cljs in my project folder after changing the package.json shadow version. I have to change it here too?

thheller17:11:54

/home/kevin/0work/guardian-dashboard/package.json

thheller17:11:58

which version is declared in there?

vigilancetech17:11:25

{
    "name": "guardian-dashboard",
    "version": "3.3.2",
    "description": "UI to JBOG guardian server",
    "main": "guardian/dashboard.js",
    "directories": {
        "doc": "doc"
    },
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1"
    },
    "repository": {
        "type": "git",
        "url": "git+"
    },
    "author": "Jessie Umblerg/Kevin Haddock",
    "license": "private trade secret",
    "bugs": {
        "url": ""
    },
    "homepage": "",
    "dependencies": {
        "electron": "^3.0.6",
        "jquery": "^3.3.1",
        "markdown": "^0.5.0",
        "npm": "^6.4.1",
        "querystring": "^0.2.0",
        "url": "^0.11.0",
        "util": "^0.11.0"
    },
    "devDependencies": {
        "shadow-cljs": "^2.7.6"
    }
}

thheller17:11:39

so something does not add up

thheller17:11:51

did you actually npm install or just edit the package.json manually?

vigilancetech17:11:14

actually I think I did npm i shadow-cljs after editing it manually

vigilancetech17:11:29

and it confirmed it installed 2.7.6

thheller17:11:36

the old version is still installed though

thheller17:11:42

did you run it in the correct directory?

vigilancetech17:11:54

pretty sure. I can try it again

vigilancetech17:11:07

all my terminal sessions are in that directory

thheller17:11:10

otherwise the good old rm -rf node_modules && npm install

☝️ 4
vigilancetech17:11:28

ok, I just did an npm i in that directory and now the package.json in the node_modules/shadow-cljs says 2.7.6

vigilancetech17:11:52

I'm pretty sure I ran the npm i shadow-cljs in there after changing the version in the package.json in the project's home folder and making it a dep in the shadow-cljs.edn and it didn't properly update it (even tho it said it did). I'll have to check that out again next time shadow's version number gets bumped to see if it does the same thing again.

thheller17:11:45

npm can be funky like that

👍 4
Wilson Velez19:11:41

are npm included libraries analyzed by google closure to eliminate not accessible code?

lilactown19:11:02

no, they're treated as foreign libraries AFAIK

thheller20:11:18

they are run through closure but only with :simple optimziations. it does some DCE but not the real stuff.

thheller20:11:38

@lilactown they are processed and not treated like foreign libs

thheller20:11:25

actual foreign libs in CLJS are not processed at all but thats partly why shadow-cljs doesnt support those 😛