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

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

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?

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

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

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

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

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

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]}}

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

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

it assumes you are using a webserver

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

saving a file reverting REPL state

just the reverse of what you described

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

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

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

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

since you can do everything directly at the REPL also

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.

... if you load it at the REPL yes

but that is the point

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

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

not exactly

if you take your repro example and run it in clojure

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

same as it is in shadow-cljs right now

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

what If I run a timer, auto load the file

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

YOU are triggering the reload

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

YOU are telling the runtime to LOAD the file from disk

in hot-reload you are NOT telling the compiler anything

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

which in the issue reported is NOT what YOU expected

but it might be what someone else expected

that is all I'm saying

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

but I don't think that is possible

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

what is done right now matches the behavior of Clojure

but it does not match the expected hot-reload behavior

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"?

will this match the behavior in Clojure?

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

Clojure do have a few hot-reload stuff

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

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

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.

no the point is that this is done automatically

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

yeah, that is automatically

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

so if I alt+tab to a browser or so

it'll save all files

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

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

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

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

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

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

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

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

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

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

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

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

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

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

reloading the browser should definitely bring everything into the expected state

since all REPL state is gone anyways

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

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

(whatever cider command that is)

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

load-file as in the nrepl command

I don't think so.

the problem is I can break the state very easily

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

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

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

just need to think about the fix for a bit

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.

But in Clojure , you only care about the namespace.

not sure what you are refering to currently

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

like auto rerun test when saving the file.

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

I mean, user care about the running state.

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

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

I just want to provide some possible solution.

not argue about something.

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

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

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

that would be a really hard problem though

ohh, I know.

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

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

in this case, just reload the browser?

that will be fine

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

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

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

since that prevents the browser-reload from fixing itself

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

file

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

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

absolutely will fix my problem

yes, funny enough that is the weird problem to fix

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

then you define the ns in the REPL

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

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

that's the expected behavior

I said, user care about the running state.

no now you are misunderstanding me

I'm not misunderstanding

I mean that is the order of events in the code

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

without adding an extra step that does not exist yet

I think you misunderstanding the purpose of the repro

my repro is how to get the bad state

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

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

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

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

but you should NOT be forced to

let me have a try

no no no, the problem is not here

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

it is when after hot-reload

after hot-reload, the output js file is empty

that is my problem

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

let me try

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

must be an actual load-file

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

and that is surprisingly confusing

the color..

I'm trying

can't reproducing..

reproduce what?

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

just require?

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

[: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"]}

I got this

I do this after I refresh the browser

hmm dunno it worked when I tested it last

but regardless the underlying problem is the same

two competing resources with no clear rules which to use

is this an error from shadow server?

yes

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

refreshing the browser does not affect the server

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

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

emmm

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

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