Fork me on GitHub
#shadow-cljs
<
2019-07-26
>
Nolan00:07:37

in a release for the :browser target, has anyone experienced local paths appearing in the build artifact? im trying to figure out where that might be leaking in

Nolan00:07:43

_where:"/Some/local/path" is in the shadow provide exports

caleb.macdonaldblack03:07:55

I've never uploaded a package to clojars before. I'm looking to wrap an npm library and publish that on clojars. Could anyone help me understand the build and publish process or point me somewhere I can learn more about it?

thheller07:07:38

@nolan that is probably something doing a require("package.json"). some js packages do that

wizard 4
clj 4
🤝 4
sheepy 4
Nolan07:07:42

confirmed that this is whats happening. not a problem was just curious where that might be coming from. thanks a million as always @thheller

thheller07:07:33

feel free to open an issue about that. the fields added by npm/yarn should probably be removed so they don't pollute the build

👍 4
Nolan07:07:42

ill open one to keep it on the radar and easy to track. its not a particularly harmful thing but seems extraneous to the artifact and worth being aware of

thheller07:07:15

yeah I want to look into what webpack does for this case

romain09:07:15

Hm... I just tested the template (shadow-cljs + reagent) by @jacek.schae https://github.com/jacekschae/shadow-reagent It works in watch mode, but when I do compile or release, index.html is throwning this error TypeError: app.core is undefined whereas file exists and is set in shadow-cljs.edn

:modules
        {:main
         {:entries [app.core]}}

thheller09:07:00

look at the console and make sure you are not getting a 404 for the JS?

thheller09:07:02

(in case you open index.html directly of the filesystem you need to change the path)

thheller09:07:21

it assumes you are using a webserver

romain10:07:12

Yes I wanted to open it directly. I just had to change paths in index.html, sorry for the noise 😉

tianshu19:07:28

https://github.com/thheller/shadow-cljs/issues/530#issuecomment-515574124 I think it's a little hard to avoid something even you knew it.

thheller19:07:42

@doglooksgood wouldn't just using whatever the load-file-in-repl command is in emacs/cider solve this problem? that should be working normally?

thheller19:07:20

I fully agree that this situation is bad ... but I cannot easily fix it without possible breaking someone elses workflow

thheller19:07:50

there should not be a problem in a purely driven REPL workflow

thheller19:07:05

only if you combine the REPL workflow with the hot-reload the problem appears

thheller19:07:45

strictly speaking you also don't need to restart shadow-cljs. just the watch but thats besides the point

tianshu19:07:22

what cider-load-file does is let you select a file, then it load.

thheller19:07:05

I don't know anything about cider but any clj/s REPL has a built-in command for load-file which force loads the actual file from disk

thheller19:07:40

should be something for that in cider just no clue what the name is

tianshu19:07:48

It's more like a function, you can write (cider-load-file "some.clj") in elisp. but as almost every tutorial they will teach user use a command called C-c C-k, that is cider-load-buffer. will load current buffer.

thheller19:07:18

if that translates to a load-file then that should be fine

tianshu19:07:52

no that simple, because cider have many commands, like it can load a file from beginning to current cursor position.

tianshu19:07:32

it can also only re-evaluate the current ns form to let require change affected.

thheller19:07:32

yes but fundamentally there SHOULD be a way to fix you problem just via the REPL

thheller19:07:47

the issue you reported is due to the REPL workflow not playing nice with the hot-reload

thheller19:07:07

which you can however fix with a pure REPL solution (without restarting anything)

thheller19:07:45

I'm just not sure how to reliable find a solution that works in an acceptable manner for both workflows

thheller19:07:59

I'm probably overthinking it and should just throw away intermediate REPL state

thheller19:07:22

but that might then create problems for someone that prefers the REPL as the ultimate truth

tianshu19:07:23

what is the another workflow in this context, and how that will be broken

thheller19:07:48

saving a file reverting REPL state

thheller19:07:07

just the reverse of what you described

thheller19:07:32

you eval something at the REPL like (defn foo [] 2) but in the file you have (defn foo [] 1)

thheller19:07:43

you save the file, it gets loaded and your REPL state is "reverted"

thheller19:07:32

it is just fundamentally a problem with hot-reload and REPL combined

thheller19:07:55

in your workflow you can probably get rid of hot-reload entirely

thheller19:07:11

since you can do everything directly at the REPL also

tianshu19:07:43

The Clojure didn't have a hot-reload. But in Clojure, When you save a file and load it, it will revert the REPL state.

thheller19:07:06

... if you load it at the REPL yes

thheller19:07:17

but that is the point

thheller19:07:30

YOU have to trigger the reload. which you can do with a load-file right now.

tianshu19:07:38

yeah, not matter how you load the file, it will finally be loaded via REL

thheller19:07:45

not exactly

thheller19:07:07

if you take your repro example and run it in clojure

thheller19:07:25

just adding the :require to foo.core will NOT trigger a reload of bar.core from disk

thheller19:07:34

same as it is in shadow-cljs right now

tianshu19:07:50

that's because there's no hot-reload stuff

tianshu19:07:03

what If I run a timer, auto load the file

thheller19:07:14

yes ... you are misunderstanding what I'm saying

thheller19:07:22

YOU are triggering the reload

thheller19:07:45

if you do it manually or via some other kind of timer or whatever does not matter

thheller19:07:56

YOU are telling the runtime to LOAD the file from disk

thheller19:07:09

in hot-reload you are NOT telling the compiler anything

thheller19:07:22

so it tries to do its best effort to try to understand what you want

thheller19:07:35

which in the issue reported is NOT what YOU expected

thheller19:07:42

but it might be what someone else expected

thheller19:07:46

that is all I'm saying

thheller19:07:58

just trying to think of something that doesn't break either workflow

thheller19:07:05

but I don't think that is possible

thheller19:07:38

so the "safe" guess is probably to throw away the REPL state and just reload from disk

thheller19:07:12

what is done right now matches the behavior of Clojure

thheller19:07:32

but it does not match the expected hot-reload behavior

tianshu19:07:46

I understand your point now, but how hot-reload work shouldn't be understand as "When I save the file, file content will be loaded in the REPL"?

tianshu19:07:08

will this match the behavior in Clojure?

thheller19:07:25

as you said .. there is no hot-reload in clojure

tianshu19:07:34

Clojure do have a few hot-reload stuff

thheller19:07:48

for example in Cursive there is a "sync files in REPL" command which I use quite frequently

👀 4
thheller19:07:58

it'll just load all the files I changed in the REPL

tianshu20:07:11

but rarely people use it, that what I mean you won't care about this workflow in Clojure. That doesn't mean you can't hot-reload in Clojure.

thheller20:07:31

no the point is that this is done automatically

thheller20:07:47

the issue wouldn't exist if YOU told the runtime to do this

tianshu20:07:53

yeah, that is automatically

thheller20:07:10

in cursive for example it will safe the file if I switch app focus

thheller20:07:18

so if I alt+tab to a browser or so

thheller20:07:21

it'll save all files

thheller20:07:40

with hot-reload it automatically loads all those files even if I didn't mean to

thheller20:07:11

so if say I was working on a function that was in a working state

tianshu20:07:16

what if you do what I do in cursive, cursive didn't restrict that

thheller20:07:24

but now I broke it since I wanted to look something up in the docs or so

thheller20:07:41

the hot-reload will blow away the REPL state even though I didn't want it to

thheller20:07:05

thats why I mean that hot-reload and REPL are somewhat at odds with each other

tianshu20:07:20

I can't understand this case, cause If I don't want hot-reload triggered, I just NOT save the file.

thheller20:07:00

as I said ... I use the "save on focus lost" as a default in Cursive

thheller20:07:07

so I don't even notice it (or could stop it)

tianshu20:07:33

That's the thing that it matches the usage in cursive, but not in Emacs

thheller20:07:21

yes ... but you see how there are multiple workflows and how fixing one can break another?

thheller20:07:44

just saying that I want to consider a proper solution first before coming up with a quick fix that fixes your particular problem

tianshu20:07:18

The only way I think can fix both is add a priority config.

thheller20:07:40

well the real problem I want to fix first is that reloading the browser makes the problem worse

thheller20:07:53

reloading the browser should definitely bring everything into the expected state

thheller20:07:58

since all REPL state is gone anyways

tianshu20:07:48

If reload can bring everything correct, this issue is kind of fixed IMO.

thheller20:07:32

the issue should be fixed just fine if you issue a load-file manually

thheller20:07:46

(whatever cider command that is)

tianshu20:07:04

But I want to say, in Clojure, there're some auto test libraries, that will auto reload test when file is saved.

thheller20:07:08

load-file as in the nrepl command

tianshu20:07:03

I don't think so.

tianshu20:07:36

the problem is I can break the state very easily

tianshu20:07:54

of course, I know when it happen, so I avoid this.

thheller20:07:54

I can fix the problem state in your repro with a simple load-file

thheller20:07:47

but that really doesn't matter ... we completely agree that the current state is bad and needs to be fixed

thheller20:07:59

just need to think about the fix for a bit

tianshu20:07:55

The problem is in Clojure you don't have to do this. I don't know how the workflow you mentioned will work with auto-test-refresh in Clojure.

tianshu20:07:21

But in Clojure , you only care about the namespace.

thheller20:07:37

not sure what you are refering to currently

tianshu20:07:18

I mean, there're some Clojure library have hot-reload works as the way I expect.

tianshu20:07:35

like auto rerun test when saving the file.

thheller20:07:04

that is relevant why? I mean I just said that we agree that this needs to be fixed?

tianshu20:07:39

I mean, user care about the running state.

tianshu20:07:13

So there should be a way to configure how running state be affected.

thheller20:07:34

lets define it this way: when you use hot-reload you care more about that the state of the REPL matches what is saved in files

tianshu20:07:38

I just want to provide some possible solution.

tianshu20:07:49

not argue about something.

thheller20:07:04

and you do not care about the state of the REPL itself

tianshu20:07:04

If the reload problem get fixed, I think I have an idea for the workflow problem

tianshu20:07:40

that is indicator, telling your current file is not sync with the repl state.

thheller20:07:02

that would be a really hard problem though

tianshu20:07:33

ohh, I know.

thheller20:07:09

I think it should be fine if I fix the real problem in that a browser-reload fixes the actual problem instead of making it worse

thheller20:07:46

requiring a full shadow-cljs build restart shouldn't be required

tianshu20:07:28

in this case, just reload the browser?

tianshu20:07:31

that will be fine

thheller20:07:18

that this "empty" file exists in disk is the real problem

goog.provide('bar.core');
goog.require('cljs.core');

//# sourceMappingURL=bar.core.js.map

thheller20:07:32

since that prevents the browser-reload from fixing itself

tianshu20:07:48

what will this file be looks like if that is fixed? the content of repl or the content of file?

tianshu20:07:40

😢 I think we are talking in the wrong direction for about a long time

tianshu20:07:22

If this is the content of file, all goes well.

tianshu20:07:46

absolutely will fix my problem

thheller20:07:25

yes, funny enough that is the weird problem to fix

thheller20:07:10

in your repro you first SAVE bar.core. shadow-cljs watch kicks in and finds that the file is not used in the build so it is not compiled

thheller20:07:22

then you define the ns in the REPL

thheller20:07:39

then you add the require. require will find the ns loaded in the REPL and not recompile the file

thheller20:07:57

since bar.core is never changed it isn't automatically replaced

tianshu20:07:24

that's the expected behavior

tianshu20:07:45

I said, user care about the running state.

thheller20:07:54

no now you are misunderstanding me

tianshu20:07:09

I'm not misunderstanding

thheller20:07:11

I mean that is the order of events in the code

thheller20:07:28

there is no step in this order of events where I can generate the correct file

thheller20:07:39

without adding an extra step that does not exist yet

tianshu20:07:42

I think you misunderstanding the purpose of the repro

tianshu20:07:01

my repro is how to get the bad state

tianshu20:07:22

not show how it won't work in this kind workflow.

thheller20:07:31

yes and I'm telling you how it ends up in that bad state from the view of shadow-cljs

tianshu20:07:14

I was thinking you are telling me, the file should be never load, unless I trigger something

thheller20:07:53

no, you CAN do that right now without me changing anything

thheller20:07:58

but you should NOT be forced to

tianshu20:07:44

let me have a try

tianshu20:07:21

no no no, the problem is not here

thheller20:07:31

(load-file "/full/path/to/bar/core/cljs") in the REPL however that is done in cider should fix it

tianshu20:07:42

it is when after hot-reload

tianshu20:07:01

after hot-reload, the output js file is empty

tianshu20:07:08

that is my problem

thheller20:07:37

if you do an actual load-file it should not be empty

tianshu20:07:49

let me try

thheller20:07:50

(require 'bar.core :reload) is broken so that does not fix it

thheller20:07:59

must be an actual load-file

thheller20:07:45

I know what the problem is ... just need to find a proper way to fix it in the actual implementation

thheller20:07:59

and that is surprisingly confusing

tianshu20:07:49

the color..

tianshu20:07:56

I'm trying

tianshu20:07:45

can't reproducing..

thheller20:07:08

reproduce what?

tianshu20:07:06

how can I do load file in shadow-cljs repl without cider

tianshu20:07:11

just require?

thheller20:07:27

(load-file "/full/path/to/bar/core.cljs")

tianshu20:07:59

[:result {:type :repl/error, :ex #error {
 :cause "symbol bar.core already provided by [:shadow.cljs.repl/resource \"bar/core.cljs\"], conflict with [:shadow.build.classpath/resource \"bar/core.cljs\"]"
 :data {:provide bar.core, :conflict [:shadow.cljs.repl/resource "bar/core.cljs"], :resource-id [:shadow.build.classpath/resource "bar/core.cljs"]}

tianshu20:07:03

I got this

tianshu20:07:52

I do this after I refresh the browser

thheller20:07:29

hmm dunno it worked when I tested it last

thheller20:07:36

but regardless the underlying problem is the same

thheller20:07:46

two competing resources with no clear rules which to use

tianshu21:07:09

is this an error from shadow server?

tianshu21:07:49

so when I refresh the browser, the state won't change

thheller21:07:06

refreshing the browser does not affect the server

tianshu21:07:58

so the namespace will be associate with the repl resource forever?

thheller21:07:26

load-file should be overwriting that but could be that it doesn't

tianshu21:07:42

looks like this is the only problem need to be solved.

thheller21:07:57

yeah I'll fix it eventually. too tired now though.

🎉 4
❤️ 4