:js-options {:js-provider :import} controls how JS packages are bundled, or in case of :import not bundled and just imported at runtime

or alternative :keep-as-import #{"fs"} to only import fs at runtime, but bundle others

https://github.com/squint-cljs/squint/blob/main/shadow-cljs.edn#L5 ?

thanks, the latter is what I need

no, this is not about the squint lib itself, it's an example project in which squint is used in a shadow project

ah

where do I put that keep-as-import again? this didn't have any effect:

{:deps {:aliases [:shadow]}
 :builds
 {:squint.embed
  {:target :esm
   :keep-as-import #{"fs"}
   :runtime :node
   :output-dir "out"
   :modules {:eval {:init-fn squint.embed/init}}
   :build-hooks [(shadow.cljs.build-report/hook
                  {:output-to "report.html"})]}}}

:js-options

this did the trick, thanks!

but if you are targetting node anyways I'd just use :js-provider :import

yeah maybe, I do think in this case, squint itself should be bundled

but that could be done by some JS tool as well probably

the fuck kinda code uses undefined as a variable name 😛

I suspect that confuses the closure compiler. no clue though, so my only guess

note that there is https://github.com/google/closure-library/blob/master/closure/goog/events/keyhandler.js

Right. But it doesn't provide the "listen for this particular key press" functionality and seems to be mostly dealing with the quirks of ancient browsers or some very specific keys on Mac.

I used it for the keyboard control in the shadow-cljs UI

I hooked it up to emit the regular event style maps, so a handler for example can use a keyword for a specific key combo

https://github.com/thheller/shadow-cljs/blob/a11f6ab9824dfaaad544dc667c405977000a1bbe/src/main/shadow/cljs/ui/components/inspect.cljs#L681

On the one hand, I really don't want to write all the necessary cruft so support stuff like "on Win/Linux Meta is Meta and Alt is Alt and undo is Ctrl+Z but on Mac, Command is Meta and Option is Alt and undo is Command+Z". On the other hand, I really don't want to study and introduce a new library that has a high chance of dealing with something in a crappy way (Mousetrap hasn't been maintained for years, and there are multiple issues). Damn programmers, they ruined programming. :D

keep it simple I'd say 😉

I wish I could. But on top of proper cross-platform shortcuts, they also need to be assignable.

I mean this is a tiny amount of code to get this event hookup thing I have in the UI

https://github.com/thheller/shadow-grove/blob/master/src/main/shadow/grove/keyboard.cljs

I'm sure you can build something for your use case in about the same amount of code

most of the complicated stuff is taken care of by KeyHandler

Maybe. But the amount of code that they have there, and how seemingly 90% of it is useless in modern browsers makes it daunting. Do you see anything wrong with this code BTW? Tried just js/document, but same thing - nothing's printed.

(let [listener (KeyHandler. (.-body js/document))]
  (.listen listener "keydown" (fn [evt]
                                (js/console.log "keydown" evt)))
  (.listen listener "keypress" (fn [evt]
                                 (js/console.log "keypress" evt)))
  (.listen listener "keyup" (fn [evt]
                              (js/console.log "keyup" evt))))

the event is "key", no clue if any others are emitted or supported

Oh, that's bloody terrible for me then. :D I need to support shortcuts like Ctrl+Shift. Which can also be pressed as Shift+Ctrl. Which must not be confused by the app with e.g. Ctrl+Shift+x.

It seems that if I rely only on KeyboarEvent.code, I don't have to deal with any crap that pretty much all of the hotkeys libraries that I've seen are designed to deal with. So it all becomes much simpler. However, there's still that bullshit of "if e.g. Space is registered as a hotkey for action X, but the focus is in an input element that supports Space, the event should be handled by that input element". Doesn't seem like there's a proper and easy way around it.

I usually handle it like this

https://github.com/thheller/shadow-cljs/blob/a11f6ab9824dfaaad544dc667c405977000a1bbe/src/main/shadow/cljs/ui/components/inspect.cljs#L676

so it ignores the event when inside codemirror

so its keybinds just work as normal. pretty simple to express it that way I think

Yeah, similarly I'm checking for the type of .-target and naively deciding whether a particular key combination is handled by the input. So e.g. if <input type="text> is in focus, pressing Space will emit a space character but pressing Ctrl+Space will check whether there's such a global binding.

IIRC you shouldn't use .code though

can't remember which one you are supposed to use, but one of them didn't respect keyboard layouts or remaps

I have caps lock rebound to ctrl, and I think .code would still give you capslock

and respecting chinese and other weird language that use code sequences for one character

keyboards are really weird

What does "rebound" mean exactly? I have F14 on my Apple keyboard mapped to ScrollLock in the kernel module - that emits ScrollLock just fine.

> For example, the code returned is "`KeyQ`" for the Q key on a QWERTY layout keyboard, but the same code value also represents the ' key on Dvorak keyboards and the A key on AZERTY keyboards. Mm, OK. But shouldn't matter that much since truly special logic is only reserved for modifiers, and those are determined based on .-key. And I plan to make all of the predefined bindings adjustable, so since setting and using a keybinding will be done with the same keyboard and the same layout (presumably), I should be good.

There is one non-trivial problem where pressing Alt+Shift in Ubuntu generates exactly what you'd expect, but pressing Shift+Alt results in "keydown Shift, keydown Meta, [...keyups...]". But eh, I'll deal with it if anybody complains.

the code seems to be failing in your code, so you tell you what you are doing there and I tell you what might have changed 😛

I mean thats a lot of versions inbetween, so there are likely things that have changed

(I'm assuming here optimus is your code. I have no idea what that is)

it is not code from shadow-cljs

could also be that you turned off source maps? and it is expecting to find some? no clue really

I'll tell you it was working before 😅 . I'll will investigate it. But the basic is

(clean-compiled-resources)
  (export-image-assets-and-replace-paths)
  (export-deeplinking-assets)
  (shadow/release environment {:verbose true})
  (compile-sass)
  (export-assets)

:compiler-options  {:optimizations                      :advanced
                                   :source-map                         true
                                   :source-map-include-sources-content true}

which :target is the build using?

I mean /js/compiled doesn't look like a valid output-dir to me? unless you are actually putting them at your fs root?

so many questions ...

source map emission has not changed, well that is unless they are empty. in that case there are no longer generated

I'm checking with version 2.22.2

the source map change was 2.26.3 https://github.com/thheller/shadow-cljs/blob/master/CHANGELOG.md

so maybe try 2.26.2 to see if it still works

or you know look at what that optimus code is doing and go from there

much faster than me guessing randomly

yes, so what is your advice about the map?

there is no advice to give. I don't know what the problem is this tool I don't know has.

I don't know enough about what you are building

I know basically nothing

files that have actual JS code in them still have source maps

so their functionality has not changed in any way

and this mostly only affected :target :npm-module, so is you build using that

or is you build generating empty output files in the first place

look at what your :output-dir looks like, I don't have enough information to provide any tips

well, I'm using the :modules to split into many .js

that is fine. if one of them very tiny or empty?

you know less than 100 bytes?

did you check the build report? https://shadow-cljs.github.io/docs/UsersGuide.html#build-report

no, higher than 100 bytes

I'm still on the vague guess that this is related to this change at all

so, instead dig into optimus

this is not code shadow-cljs uses or provides, so I'm completely in the dark

great thank your help effort, I'll investigate it.

to give more details

I mean are the .map files in the :output-dir or not?

totally possible that the change had unintended consequences

I couldn't see even the compiled files over there

so, no .map into output

so the build fails?

fails in that part

I see you are using (shadow/release environment {:verbose true}) which will not throw an exception if it fails

Caused by:
Exception: No files matched regex /js/compiled/.*\.js\.map

you likely want to use release! instead

that error is not a message from shadow-cljs. and not related to a shadow-cljs build failure at all. it just happens to run after shadow-cljs completes or maybe fails in this case

just run npx shadow-cljs release your-build without all this additional stuff

and see if it completes properly or not

yes, but I reached here because I couldn't see the compiled *.js

yes, then run the above command and tell me why

all your additional extra stuff I cannot comment on or help with

with actual shadow-cljs stuff I can help. I suspect now that the build is just failing and your setup not correctly identifying it and trying to continue as if everything was fine

I think I got the error:

switch (a) {
            case V.types.logCustomEvent:
              import("./log-custom-event.js").then(
                ({ logCustomEvent: logCustomEvent }) => {
                  e.so()
                    ? ((i = Array.prototype.slice.call(s)),
                      logCustomEvent(...i))
                    : r.error(_);
                },
              );

ok. that is an error from the closure compiler and it never actually worked. could be that it was just ignored before.

now is it not?

yes. this is not something shadow-cljs can do anything about. it is entirely within the closure compiler.

🤒

if you need code like this then you can use a different JS bundler via https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external

I don't know what this code is and if it was ever actually used or if you can avoid it

this was cause by introducing a new npm package

then remove it 😉

😅 if I could

https://github.com/google/closure-compiler/issues/3941

dammit 😱

which npm package is this?

braze

So, @U05224H0W I'll try to use js-provider-external, but what about the problem with module split? I have 5 splitting modules.

is there a problem with it? Using with webpack.

depends. CLJS modules is fine and doesn't change. however the JS code will all end up in that single external file, which may not be ideal. https://github.com/thheller/shadow-cljs/issues/1162

you mean, at the end, all split files will be joint to a single .js ?

no

:external creates an :external-index file which you process with webpack

the file it generates contains ALL JS dependencies

the CLJS output is still just the 5 modules you configured

so you have a total of 6 .js files

oh ok, understood

note that I just added support for this style of import that JS package is trying to do

so if you try 2.26.6 it may just work, couldn't try the actual package since I didn't find it. https://www.npmjs.com/package/braze didn't seem to be it

oh great !!!

but should I run it normally?

yes, as before

I'd appreciate your effort

and the Closure error compiler gone too?

the package is https://www.npmjs.com/package/@braze/web-sdk

I don't know if the error is gone. It might be. I didn't try the package but the problematic snippet you posted above should now be fine and not produce an error

just tried the package. doesn't work. I mean it compiles fine now, but produces a runtime error

I'm guessing some kind of other code pattern the closure compiler doesn't like

no time to look into that one now

Yes, I got this error too:

yeah that one

Hello, do you think is it worth to work with that fixes?