Fork me on GitHub
#shadow-cljs
<
2018-08-28
>
grav07:08:21

Can't get deps.edn and Reagent working together. I end up getting The required namespace "react" is not available, it was required by "reagent/core.cljs".

grav07:08:56

I have :deps true in my shadow-cljs.edn, and :deps {reagent {:mvn/version "0.8.1"}} in my deps.edn

thheller07:08:19

@grav deps.edn doesn't cover installing npm deps at all. npm install react react-dom create-react-class is required manually since reagent doesn't declare those :npm-deps.

grav08:08:52

ah, of course

thheller08:08:00

https://github.com/thheller/shadow-cljs/issues/382 I'll try to find a way to make this smarter

hlolli08:08:27

was there ever a discussion about having tools-deps support installing npm packages?

thheller08:08:48

no idea. the odds of that happening are probably near zero though.

thheller08:08:32

just the nature of npm deps is so anti-clojure best practice its not even funny

thheller09:08:28

version ranges as the default, running globally vurnable things on install,postinstall,etc

hlolli09:08:23

yes, so just have yarn or npm do all the work of resolveing the dependencies. Just have 1 file to assemble all the deps needed to build a project. :npm/yarn or :npm/npm to specify the resolver.

thheller09:08:04

but whats the point of that? package.json and npm install already cover that

thheller09:08:38

yarn also uses the same npm registry so it doesn't really make sense to differentiate between yarn and npm in the dep location

hlolli09:08:26

the only point is simplification. Especially if the package.json is stored in a .jar file. Just manual labour.

thheller09:08:06

but it isn't simpler

hlolli09:08:11

and why would it then make a difference if the user makes a package.json or deps.edn stores it, same end result

thheller09:08:25

but how do you resolve conflicts?

thheller09:08:52

lib A depends on react v16, lib B depends on react v15

thheller09:08:58

which one do you pass to npm install?

thheller09:08:28

its annoying as it is with deps.cljs and :npm-deps

hlolli09:08:33

you pass the entry point to npm install and lib A and lib B to nested dependencies and npm resolves it like it would

thheller09:08:11

clojure lib A and B

thheller09:08:22

not npm lib A and B

thheller09:08:09

its probably all solvable but IMHO it should just be left with npm.

thheller09:08:39

I also personally have no interest in deps.edn

hlolli09:08:57

yes, my whole point is to leave it to npm, if deps.edn declares a npm dependencies, then npm should treat the npm dependencies like it was a module.

thheller09:08:25

I guess I don't understand what you are saying then. npm doesn't know about deps.edn

hlolli09:08:12

that's right, there could be a mechanism to export package.json and then require it.

thheller09:08:18

I'm saying CLJ lib A declared :deps {"react" {:npm/version "v16"}} and lib B declares :deps {"react" {:npm/version "v15"}}

thheller09:08:31

which one do you pass to npm

thheller09:08:36

you can't pass both

thheller09:08:44

resolving npm version ranges is a nightmare

hlolli09:08:04

you pass libA and libB to npm. Then you have conflict like you'd always have in this situation.

thheller09:08:33

what do you mean by pass libA and libB to npm

hlolli09:08:00

node_modules/libA/package.json["react" "v16"] node_modules/libB/package.json["react" "v15"] entry ./package.json {"dependencies":{"libA" "...", "libB": ".."}

hlolli09:08:00

that root package.json doen't really have to exist, could be a stream

hlolli09:08:24

don't know, just throwing ideas

thheller09:08:51

node_modules/libA doesn't exist though?

thheller09:08:57

its maven package?

hlolli09:08:00

yes, so it would exist in ~/.m2, tools.deps, could theoretically, read the deps.edn from the maven resources, and spit package.json, or somehow resolve it, and run npm install from the directory it was called from to generate node_modules

hlolli09:08:56

when and only npm modules are a dependency of an application, which are these days, most clojurescript apps.

hlolli09:08:40

but yes, if all the maven deps are themselves a module, they may resolve conflicts, but they are themselves a module but not their dependencies. So it doesn't make sense what I said, in the sense that we want the dependencies to be first class, and then it surely can conflict.

hlolli09:08:57

what goes against always choosing the higher version?

thheller09:08:40

its not how npm works, due to their use of version ranges everywhere

thheller09:08:24

^16.0.0 doesn't match ^15.0.0

thheller09:08:58

but don't take my work for any of this. I'm not qualified to commend on any deps.edn issues. ask in #tools-deps what their plans are

hlolli09:08:17

unrelated, I worry about react17; componentWillReceiveProps and componentWillUpdate are going to get deprecated and renamed with UNSAFE_ prefix. React libraries are going to get "doesn't work on my computer" storm soon.

😥 4
thheller09:08:24

yep. fun times ahead.

chrisetheridge13:08:34

has anyone seen this error with datascript and shadow-cljs before?

chrisetheridge13:08:08

seems to have gone after a rebuild

chrisetheridge14:08:50

what do “js/my-fn is shadowed by a local” errors point to?

thheller14:08:53

(let [my-fn ...] (js/my-fn ...))?

chrisetheridge14:08:00

navigate-fn in this case is: js/history.replaceState or js/history.pushState

thheller14:08:20

is there a (def history ..)?

chrisetheridge14:08:19

removing:

(and (relative? url)
            (exists? navigate-fn))

chrisetheridge14:08:41

and its down to the (exists? ...) call

chrisetheridge14:08:39

using (some? ...) works

thheller14:08:43

ah right. exists? only works for globals

thheller14:08:56

if (some? navigate-fn)

chrisetheridge14:08:06

would js/history not be a global though?

chrisetheridge14:08:14

i guess it cannot see that at compile time

thheller14:08:29

exists? is basically only for global constants yes

urbanslug14:08:01

When using shadow-cljs with deps.edn say I have one build :app and I have two aliases :dev and :production in my deps.edn

chrisetheridge14:08:05

is this not enforced in other compilers?

urbanslug14:08:22

In both cases I want to run the build called app

urbanslug14:08:48

Is there a way to tell the build when to use which deps.edn alias?

urbanslug14:08:44

even if I were to break the build :app into two (dev and prod) specifying the alias seems to take place outside the :builds value; on the same level actually.

urbanslug14:08:59

I could share the code if it'll help

thheller14:08:02

@urbanslug that is not possible, a build cannot be tied to an alias

urbanslug14:08:25

well in this case re-frame tracing says to use different deps for prod and dev

thheller14:08:27

shadow-cljs -A:production release app

thheller14:08:46

you can do that though

urbanslug14:08:15

and it'll download all other deps plus the one in production, right?

urbanslug14:08:16

seems to work

urbanslug14:08:44

ran into an error but hmm probably unrelated

urbanslug14:08:53

worked ok with just shadow.cljs

urbanslug15:08:24

{:deps
 {reagent                     {:mvn/version "0.8.0"}
  re-frame                    {:mvn/version "0.10.5"}
  day8.re-frame/http-fx       {:mvn/version "0.1.6"}
  secretary                   {:mvn/version "1.2.3"}
  com.andrewmcveigh/cljs-time {:mvn/version "0.5.2"}
  proto-repl                  {:mvn/version  "0.3.1"}
  devcards                    {:mvn/version "0.2.5"}
  binaryage/devtools          {:mvn/version  "0.9.10"}
  day8.re-frame/re-frame-10x  {:mvn/version "0.3.3-react16"}}
 :aliases
 {:dev
  {:extra-deps
   {day8.re-frame/tracing-stubs {:mvn/version "0.5.1"}}}
  :prod
  {:extra-deps
   {day8.re-frame/tracing {:mvn/version  "0.5.1"}}}}}

urbanslug15:08:40

Error building classpath. Could not transfer artifact thheller:shadow-cljs:jar:2.6.3 from/to clojars (): Range Not Satisfiable (416)

urbanslug15:08:42

the jar doesn't exist

urbanslug15:08:48

it's an npm module

thheller15:08:51

no idea. its probably clj printing that

thheller15:08:00

no its a jar

thheller15:08:09

you have the aliases switched btw

thheller15:08:17

prod should include the stubs not the other way

thheller15:08:25

none of that is relevant

urbanslug15:08:27

Ok I should use gists

thheller15:08:28

just run clj

thheller15:08:38

it should throw the same error on startup

urbanslug15:08:49

I thought it was my shadow-cljs.edn

thheller15:08:21

ah nvm it won't print the error on startup because the dep is injected dynamically

thheller15:08:37

just add thheller/shadow-cljs {:mvn/version "2.6.3"} to your :deps

thheller15:08:47

then run clj

thheller15:08:33

these -stubs packages are starting to bug me ... I really dislike the entire concept

thheller15:08:32

^ its not relevant

urbanslug15:08:57

I thought I could be messing up in the shadow-cljs.edn

thheller15:08:14

you are but that doesn't matter

thheller15:08:34

it doesn't even get that far

urbanslug15:08:58

but it's not on clojars > just add thheller/shadow-cljs {:mvn/version "2.6.3"} to your :deps

thheller15:08:05

of course it is

urbanslug15:08:16

clj is downloading deps now

urbanslug15:08:42

successfully done

thheller15:08:33

did you cheat and use 2.6.4?

urbanslug15:08:36

Same error on shadow-cljs -A:dev watch app;

urbanslug15:08:00

naah I used 2.6.3

urbanslug15:08:09

clj ran successfully

urbanslug15:08:51

trying with 2.6.4 same error about being unable to transfer 2.6.3

thheller15:08:15

ok show me you deps.edn please

thheller15:08:58

run clj -A:dev -m shadow.cljs.devtools.cli watch app please

urbanslug15:08:51

Exception in thread "main" java.io.FileNotFoundException: Could not locate shadow/cljs/devtools/cli__init.class or shadow/cljs/devtools/cli.clj on classpath.

thheller15:08:17

is that actually your deps.edn?

urbanslug15:08:45

Yup I could push my changes and you pull and clone to test

urbanslug15:08:54

Could be something in my env that's messed up

thheller15:08:04

I mean is it saved on disk and you are in that actual directory?

thheller15:08:17

the error above suggests that shadow-cljs is not actually on the classpath

urbanslug15:08:09

yup, well shadow-cljs is installed in the node modules via npm not for my user but I did run clj after adding it to deps.edn so it should be

thheller15:08:24

don't confuse node_modules with that is happening

urbanslug15:08:38

Ok what is happening is that it's not in .m2

thheller15:08:07

two parts. the npm package is completely independent from all the clojure stuff

thheller15:08:28

the clojars package is the one we are interested in at the moment

urbanslug15:08:37

shadow-cljs is def not in my ~/.m2/repositories

urbanslug15:08:58

I'll remove it and start over

thheller15:08:24

it would be in .m2/repository/thheller/shadow-cljs

urbanslug15:08:01

darnit I already deleted my .m2 but I can see a thheller dir was there

thheller15:08:51

what the actual ...

thheller15:08:57

I get the same error

thheller15:08:36

use parinfer or something 😛

thheller15:08:56

day8.re-frame/re-frame-10x  {:mvn/version "0.3.3-react16"}}
  thheller/shadow-cljs        {:mvn/version "2.6.3"}

thheller15:08:05

note the misplaced closing }

thheller15:08:46

should be

day8.re-frame/re-frame-10x  {:mvn/version "0.3.3-react16"}
  thheller/shadow-cljs        {:mvn/version "2.6.3"}}

urbanslug15:08:56

Ya I added it outside the deps

urbanslug15:08:43

I use emacs with paredit

urbanslug15:08:58

I should've seen the differently colored parens

thheller15:08:02

hmm and it didn't complain about that?

urbanslug15:08:27

naah clj ran just fine

thheller15:08:30

Cursive paredit would change the indent so it would be more obvious

urbanslug15:08:42

weird how $ clj and $ clojure failed after removing my ~/.m2 I thought they called the clojure bin in my /usr/bin/clojure I'm waiting for my yarn dev to finish now. It should work.

thheller15:08:16

probably clj -Sforce since you deleted files that it that would exist

urbanslug15:08:48

wooo! success!!!!

kwladyka15:08:57

What are best practice for :output-dir, :output-to, :test-dir for :target: :browser :node-test browser-test. I mean i see paths like public/js, resources/public/js, resources/public/js/out and I am trying to solve the puzzle why so many paths. Should best practice be to use path in resources or not etc. Maybe not super important but I am trying to do some guideline.

thheller15:08:46

I personally never use resources but many people do

thheller15:08:57

its really up to you

kwladyka15:08:04

Any pros / cons?

kwladyka15:08:31

For example if somebody have also server things in project?

thheller15:08:50

its just a directory. the reason is that many people want to package their .js files into uberjars. that is easier with resources/public

thheller15:08:33

depending on the server you run you can either serve a "resource" which means something that is on the classpath and the resources directory typically is in lein

thheller15:08:45

or you can serve "files" from an actual directory

kwladyka15:08:40

the reason to pack .js to uberjars are? make a module? other benefits?

thheller15:08:55

deploy one single file

thheller15:08:25

the uberjar will contain everything and serve resources

kwladyka15:08:26

oh yes, if somebody not use docker it make sense

thheller15:08:49

I don't do that since it also requires restarting your clojure server to update .js files

thheller15:08:53

which just seems like a waste

kwladyka15:08:56

so why you never use resources?

thheller15:08:34

I have an uberjar for my server but that server is configured to serve the public directory via files

thheller15:08:43

so I can swap the files at any time without restarting the server

kwladyka15:08:10

so you don’t use resources path to avoid confusion (what I understand)

thheller15:08:49

more about keeping the uberjar clean

thheller15:08:03

and not putting anything in there that doesn't have to be

thheller15:08:57

I do way more frequent releases of my frontend JS than the backend server

kwladyka15:08:59

so you put all tests to /out/… and app to /public?

thheller15:08:16

restarting the backend server every time the frontend changes sucks

thheller15:08:44

depends on the project

thheller15:08:53

one project has multiple virtual hosts

thheller15:08:21

so I output to vhosts/alias.foo.com/public vhosts/other.foo.com/public

thheller15:08:15

its really up to you and your project

urbanslug15:08:22

If you serve the frontend via reverse proxy (nginx) you don't have to restart the backend

thheller15:08:33

@urbanslug of course you do. if you only serve resources.

urbanslug15:08:51

hmmm why? the frontend is just making ajax requests to your backend

thheller15:08:31

... ok I guess you are serving the resources/public directory via nginx?

thheller15:08:50

thats cheating and not using the uberjar. in that case it would actually be waste to have the .js in the uberjar at all

thheller15:08:00

thus using resources at all being "bad"

urbanslug15:08:06

CI tool builds that dir and copies it to a dir on your server

urbanslug15:08:48

Oh I don't use an uberjar should probably read about it and see why I'd want to

thheller15:08:23

its fine not to do it

urbanslug15:08:38

Why do you do it?

kwladyka15:08:44

After change to: :output-dir "public/js" But it is running. Also I restarted server and watch app

thheller15:08:47

but your statement was just incorrect in the discussion we were having

thheller15:08:48

@kwladyka are you including the correct .js file in the .html?

🍻 4
kwladyka15:08:36

ok it is time to take a break 🙂

urbanslug17:08:07

I've noticed that tests (karma) don't work when I'm using deps.edn such as in https://gitlab.com/urbanslug/sniff

urbanslug17:08:39

is that expected?

$  CHROME_BIN=/usr/bin/chromium y test                                                                                                                                                              
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:01:16.832:INFO [karma]: Karma v3.0.0 server started at 
28 08 2018 20:01:16.834:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:01:16.839:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:01:17.119:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket VQ5gfyizvjWfbb8bAAAA with id 10361789
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 0 of 0 ERROR (0.003 secs / 0 secs)
error Command failed with exit code 1.
info Visit  for documentation about this command.

thheller17:08:07

did you compile properly? does the target/test.js exist?

thheller17:08:19

I just see you running karma (which I know very little of)

urbanslug17:08:11

Let me try again but yeah I've cleaned abd compiled

urbanslug17:08:28

$ y compile-tests                                                                                                                                                                                  urbanslug@urbanslug
yarn run v1.9.2
$ shadow-cljs compile test
shadow-cljs - config: /home/urbanslug/src/clj/sniff/shadow-cljs.edn  cli version: 2.6.4  node: v10.8.0
shadow-cljs - starting via "clojure"
[:test] Compiling ...
[:test] Build completed. (42 files, 0 compiled, 0 warnings, 2.68s)
Done in 18.53s.

urbanslug17:08:05

but when I use shadow-cljs.edn the tests work

thheller17:08:03

what does that mean? the command you just pasted used deps.edn?

urbanslug17:08:04

when my shadow.cljs file looks like so:

:dependencies [[cljs-ajax "0.7.3"]
                [reagent "0.8.0"]
                [re-frame "0.10.5"]
                [day8.re-frame/http-fx "0.1.6"]
                [secretary "1.2.3"]
                [com.andrewmcveigh/cljs-time "0.5.2"]
                [proto-repl "0.3.1"]
                [devcards "0.2.5"]
                [binaryage/devtools "0.9.10"]
                [day8.re-frame/re-frame-10x "0.3.3-react16"]
                [day8.re-frame/tracing "0.5.1"]
                ;[day8.re-frame/tracing-stubs "0.5.1"]
                ]


 ;:deps         true

thheller17:08:13

what am I even looking at? what is it supposed to say? I do not know or use karma. what is the issue here?

thheller17:08:08

you are saying the when :deps true and running shadow-cljs -A:dev compile test the tests somehow behave differently?

urbanslug17:08:56

yes > you are saying the when :deps true and running shadow-cljs -A:dev compile test the tests somehow behave differently?

urbanslug17:08:55

I didn't have the -A:dev in compile test earlier but it doesn't seem to have made a difference.

urbanslug17:08:22

A successful test run

CHROME_BIN=/usr/bin/chromium y test                                                                                                                                                             urbanslug@urbanslug
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:07:52.737:INFO [karma]: Karma v3.0.0 server started at 
28 08 2018 20:07:52.740:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:07:52.745:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:07:53.041:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket Bw4Yh8tnbBy6CuC7AAAA with id 59771053
LOG: 'Testing sniff.core-test'
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 1 of 1 SUCCESS (0.008 secs / 0.002 secs)
TOTAL: 1 SUCCESS
Done in 1.17s.

thheller17:08:43

uhm aren't namespaces missing without the alias?

thheller17:08:01

compilation probably didn't finish? so there were no tests to run?

urbanslug17:08:17

CHROME_BIN=/usr/bin/chromium y test                                                                                                                                                             urbanslug@urbanslug
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:14:29.089:INFO [karma]: Karma v3.0.0 server started at 
28 08 2018 20:14:29.091:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:14:29.095:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:14:29.380:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket KQ9yl27ydQsVoQa2AAAA with id 37908417
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 0 of 0 ERROR (0.003 secs / 0 secs)
error Command failed with exit code 1.
info Visit  for documentation about this command.
------------------------------------------------------------

urbanslug17:08:36

failed test run

thheller17:08:42

I'm much more interested in the shadow-cljs output. karma doesn't tell me anything.

thheller17:08:56

what did you run before karma?

urbanslug17:08:38

$ y compile-tests                                                                                                                                                                                 urbanslug@urbanslug
yarn run v1.9.2
$ shadow-cljs -A:dev compile test;
shadow-cljs - config: /home/urbanslug/src/clj/sniff/shadow-cljs.edn  cli version: 2.6.4  node: v10.8.0
shadow-cljs - starting via "clojure"
[:test] Compiling ...
[:test] Build completed. (42 files, 0 compiled, 0 warnings, 2.17s)
Done in 15.98s.

thheller17:08:31

your deps.edn doesn't declare any :paths ["src"]

thheller17:08:45

so it doesn't find your source files and has no tests to run?

urbanslug17:08:09

I didn't know that I needed it

urbanslug17:08:35

works now for sure

thheller17:08:55

good to know. I can probably add a warning if no source files are found

thheller17:08:10

did you not try to compile your other builds? they should have failed too?

urbanslug17:08:53

I didn't try to compile them, no.

thheller17:08:14

:source-paths ["src" "test"]

 :deps         true

thheller17:08:29

the :source-paths in shadow-cljs.edn are not used when :deps true is used

thheller17:08:49

so you need to move them to :paths in deps.edn instead

urbanslug17:08:45

hmm I guessed that it had to do with the source paths but the dev server was working with the source paths in shadow-cljs.edn so I couldn't have guessed it

thheller17:08:38

I think you are still a little confused how the things fit together

thheller17:08:00

shadow-cljs the npm package is just about starting a JVM with the proper JVM dependencies loaded

thheller17:08:14

it can either to this via lein, clojure or its built-in launcher

thheller17:08:58

unfortunately its pretty tough to check what you actually do in deps.edn so its rather hard to debug

thheller17:08:01

but thanks for digging through it

urbanslug17:08:01

I see > shadow-cljs the npm package is just about starting a JVM with the proper JVM dependencies loaded

thheller17:08:16

I can now add a bunch of steps to my checklist for future reference 😉

🙂 4
urbanslug17:08:24

idk what quality of examples you require but I'm offering that one there. If I had it at the start it would've made my life a lot easier.

urbanslug17:08:44

because the clojurescript compiler (by clojure) to compile cljs

urbanslug17:08:11

so basically what you're starting are web sockets to update the UI and listening for file changes

urbanslug17:08:35

but you're also doing really neat stuff with npm

thheller17:08:49

all in clojure

thheller17:08:28

the npm package itself is really just for starting. it does not else.

urbanslug17:08:08

I'm talking about getting packages from npm and not clojars

urbanslug17:08:17

as was (maybe still is) with lein

thheller17:08:45

I don't get any packages from npm, you do via npm install

urbanslug17:08:24

so you just check the node modules

thheller17:08:58

yes I resolve all the files that your build needs and package them together so you can load them in your page

thheller17:08:14

+ some fancy compiler tricks

urbanslug17:08:36

what about the refers? How say... I require a default export

urbanslug17:08:25

Because it's really easy here. I can have a person work in react and the default export just works

urbanslug17:08:39

not so with the other tools from what I've seen in the other channels

urbanslug17:08:47

Anywho I have too many questions 🙂

thheller17:08:30

those would be the fancy compiler tricks I guess. I made a few modifications since I wanted to use that myself. other CLJS tools can't do that yet no.

👍 4
hlolli18:08:51

Any chance to lift this restriction? At least outside of project, I'm locally debugging a lib via npm link <libname>, I could theoretically copy over the files, but perhaps lift it, if the file was seen to be a symlink, otherwise keep the same behaviour. https://github.com/thheller/shadow-cljs/blob/016c0c87241ba8bb3a5d753774c052c8661ac8ba/src/main/shadow/build/npm.clj#L431-L433

thheller18:08:18

its actually a different issue I think. it just shouldn't use the canonical file at all

hlolli18:08:51

this is a browser compilation, for node-library this doesn't happen.

thheller18:08:51

yeah. java has two ways of resolving file paths

thheller18:08:07

I'm just using the wrong one

thheller18:08:52

> A canonical pathname is both absolute and unique. The precise definition of canonical form is system-dependent. This method first converts this pathname to absolute form if necessary, as if by invoking the getAbsolutePath() method, and then maps it to its unique form in a system-dependent way. This typically involves removing redundant names such as "." and ".." from the pathname, resolving symbolic links (on UNIX platforms), and converting drive letters to a standard case (on Microsoft Windows platforms).

thheller18:08:46

I'm using it remove the .. and other relative path crap npm packages do

thheller18:08:54

but it shouldn't replace the links

hlolli18:08:26

in the quote you posted it says it does 🙂 (if you mean symlink by link)

thheller18:08:13

yes I know. I mean that I want to to replace .. and stuff but NOT follow links

thheller18:08:15

currently it does

thheller18:08:30

need to figure out if there is a way to make it not do that but still replace ..

hlolli18:08:06

without knowing it, maybe the java8 file class offers something.

thheller18:08:16

the quote I just posted is from java.io.File/getCanoncialPath 😉

hlolli18:08:38

java.nio.file.Path

Path resolve(Path other)
Resolve the given path against this path.
If the other parameter is an absolute path then this method trivially returns other. If other is an empty path then this method trivially returns this path. Otherwise this method considers this path to be a directory and resolves the given path against this path. In the simplest case, the given path does not have a root component, in which case this method joins the given path to this path and returns a resulting path that ends with the given path. Where the given path has a root component then resolution is highly implementation dependent and therefore unspecified.

thheller18:08:53

nah Path/normalize it is

👍 4
hlolli18:08:44

ah resolve is of course just like in node.fs, watched an example of stackoverflow before reading the docs, I never posted that 🙂

thheller18:08:14

yeah just want to get rid of the dots

thheller18:08:59

sometimes I wish I was using Path for everything. File really isn't all that great anymore.

thheller18:08:25

but some parts of the Path API are just annoying so meh 😛

kwladyka19:08:53

Why [2018-08-28 21:14:35.480 - INFO] :shadow.build.npm/js-invalid-requires - {:resource-name "node_modules/eth-lib/lib/bytes.js", :requires [{:line 9, :column 193}]}? Is it a bug in web3js or I am doing something wrong? I think it is connected with "web3": "^1.0.0-beta.35".

thheller20:08:22

look at the file location

thheller20:08:29

I can't tell you whats happening there

thheller20:08:47

it probably doesn't matter though since those often are conditional requires