Fork me on GitHub
#shadow-cljs
<
2018-01-27
>
thheller13:01:27

@hlolli yes that can be explained better. will do soon.

thheller13:01:59

currently still setting up windows and getting used to things

hlolli13:01:19

@thheller I'm trying to uberjar a node-library, that require thing doen't seem to find a js resource I'm requireing, I did (js/require (path/join js/dirname "fileinroot.js")), that fileinroot is inside the uberjar, but won't get extracted. Is this something known, or maybe implementing resolve for modules from node-library targets just what's needed.

hlolli13:01:07

I define it from leiningen in :reosource-paths -> lein uberjar and then it's in the .jar file

thheller13:01:09

uberjar a node library? node doesn't supports jars?

hlolli13:01:35

I should rather say, clojurescript targeting node.js.

hlolli13:01:50

ie clojurescript code that uses js/require

thheller13:01:52

how does uberjar play into this?

hlolli13:01:45

I want to create library and in another project call it. I can't see a better way of hosting cljs code than on clojars?

thheller13:01:41

uberjar includes all your dependencies into the jar

thheller13:01:53

uberjars are usually not published on clojars.

thheller13:01:16

but yes the js/require won't find things in jars

thheller13:01:57

i don't quite understand what you are trying to do

thheller13:01:17

if you want to publish a CLJS library you just publish the code, not the compiled code

hlolli13:01:35

I have a cljs project that has a single vanilla js file that has exports that I want to use in cljs land. I require it and it all works, I just want to package the whole thing, and from a different project call the cljs functions that some also call vanilla js code

thheller13:01:22

ah ok I thought you were trying the other way. consume the cljs in js.

thheller13:01:53

so the problem with .js files that you are including via js/require

thheller13:01:59

is that the compiler doesn't know about them

thheller13:01:23

and therefore won't do anything to include them in the build

thheller13:01:44

ie. copy them out of the jar so node can find it

thheller13:01:11

the problem with relative requires is that they currently only work for files

thheller13:01:28

option a) publish the .js file to npm

thheller13:01:24

unfortunately

hlolli13:01:25

yes, that can actually work in my case

thheller13:01:35

> Supporting Node.js style paths as requires is just never, ever going to happen.

thheller13:01:22

if you publish the .js file to a npm package you can just declare it in :npm-deps for the lib

thheller13:01:36

all other solutions are kinda hacky

hlolli13:01:39

yes I'll do that, seems cleanest

thheller13:01:38

I have a few outstanding ideas for better JS interop since some things aren't as clean as I'd like

thheller13:01:59

not sure when I'll get to that though

thheller13:01:13

should make including random .js files easier though

thheller13:01:36

kinda not possible to publish ES6 .js files in .jars currently which is annoying

thheller13:01:54

(or even CommonJS)

hlolli13:01:36

yes that's bit annoying, I've often thought about the other way around, just start uploading cljs stuff on npm.

thheller13:01:59

that doesn't really fix the issue though

thheller13:01:19

the problem is that clojure(script) is classpath based

thheller13:01:35

ie. you have multiple "roots" but each file must be unique on the classpath

thheller13:01:46

otherwise they override each other

thheller13:01:55

node/npm doesn't have a classpath at all

thheller13:01:59

its all just relative paths

thheller13:01:31

we could easily add a bit of metadata to package.json to declare :source-paths for a lib

thheller13:01:37

and just add those to the classpath

thheller13:01:44

but you can't break out of the classpath

hlolli13:01:52

yes, but a cljs compiler can just ignore the package.json and node ecosystem, go straight to node_modules read a package description file and resolve the classpath and files just with node_modules/packagex cut off.

thheller13:01:11

that doesn't work since the files aren't uniquely named

hlolli13:01:37

oh didnt know that

thheller13:01:03

in cljs everything is namespaced. eg. shadow.dom is in <root>/shadow/dom.cljs

hlolli13:01:07

yes, my idea is that this <root> would just have to be resolved differently for npm packaged cljs code.

hlolli13:01:32

But my stomach is telling my that it really needs food, so Im afk for now

thheller13:01:35

the classpath is a collection of paths

thheller13:01:54

so it could easiy add node_modules/some-package/src as that path

thheller13:01:36

just add package.json "clojurescript":{"source-paths": ["src"]} or something and that would work easily

thheller13:01:57

the problem is still that classpath and relative paths don't play well together

thheller13:01:22

nothing is node is named so if one file include another it must use the relative path

thheller13:01:04

since node doesn't have naming you get nice looking imports like these

thheller13:01:11

react-virtualized/dist/commonjs/AutoSizer

thheller13:01:46

hopefully js people get their act together and enable at least react-virtualized/AutoSizer at some point

thheller13:01:41

anyways ... whether CLJS is published to npm or clojars doesn't change how file refences work

tony.kay19:01:00

@thheller Just tried out the new HUD….NICE!

thheller20:01:59

kinda wanted to do more animations and stuff but its a start

thheller20:01:11

the error printing code needs work but hey at least they get displayed now

tony.kay22:01:02

I think it's really good. I care about functionality more than anything, and this is very functional.