Fork me on GitHub

Just updated shadow-cljs to the latest and started getting this warning:

[To redirect Truffle log output to a file use one of the following options:
* '--log.file=<path>' if the option is passed using a guest language launcher.
* '-Dpolyglot.log.file=<path>' if the option is passed using the host Java launcher.
* Configure logging using the polyglot embedding API.]
[engine] WARNING: The polyglot context is using an implementation that does not support runtime compilation.
The guest application code will therefore be executed in interpreted mode only.
Execution only in interpreted mode will strongly impact the guest application performance.
For more information on using GraalVM see .
To disable this warning the '--engine.WarnInterpreterOnly=false' option or use the '-Dpolyglot.engine.WarnInterpreterOnly=false' system property.
Adding -Dpolyglot.engine.WarnInterpreterOnly=false does remove it in its entirety. But that's only possible because I use deps.edn. Would people using shadow-cljs.edn for their dependencies also be able to suppress the warning? Maybe this warning something that shadow-cljs can suppress itself?


no clue what that warning is. never seen it before.


maybe you have a different graaljs engine in deps.edn? do you actually use graalvm maybe?


Nope. This is enough to trigger the warning:

{:paths ["src"]
 :deps  {thheller/shadow-cljs       {:mvn/version "2.17.8"}
         superstructor/re-highlight {:mvn/version "1.1.0"}}}
Removing superstructor/re-highlight removes the warning. That dependency doesn't have any CLJS dependencies - only deps.cljs that has this:
{:npm-deps     {"highlight.js"          "11.1.0"}
 :npm-dev-deps {"react"                 "17.0.2"
                "react-dom"             "17.0.2"
                "shadow-cljs"           "2.15.1"
                "karma"                 "6.3.4"
                "karma-chrome-launcher" "3.1.0"
                "karma-cljs-test"       "0.1.0"
                "karma-junit-reporter"  "2.0.1"}}


the warning is triggered by the graaljs engine. which I guess works differently when used on actual graalvm


the graaljs engine is used when comparing :npm-deps versions in deps.cljs files


so I guess the re-highlight has one and removing that will not cause that part of the code to run


I may just remove that check altogether or make a manual command to run


its usefulness is rather limited anyways


Is the version comparison there only to warn people about inconsistent versions?


its used to warn about conflicts in deps.cljs files


ie. reagent wanting react v16 but something else wanting react v17 or whatever


setting :npm-deps {:install false} in shadow-cljs.edn should also get rid of the warnings


But why is evaluating JS needed for that? Because of JS-based SemVer functionality?


also won't isntall any js deps though ;)


A-ha, found semver.js. If I, say, rewrote that in CLJ, would you use that instead of evaluating semver.js on GraalJS?


would be best to just implement that in clojure but npm versions are a complete mess and I really can't be bothered to figure out how it works šŸ˜›


yes, absolutely. please do šŸ™‚


Heh, will try.


One caveat - it will be harder to update once SemVer inevitably becomes 3.0.0 or even 2.0.1.


I could just remove it entirely or just bail on conflict


pretty sure everyone just ignores the warning anyway šŸ˜‰


But you can't figure out whether there truly is a conflict without doing all that crap, can you? You can only check for not=.


Naah, I check those warnings. :)


don't know. there are definitely deps.cljs with version ranges out there


God damn. That code is a complete mess, its semantics notwithstanding.


Actually, this raises a question - why didn't you use or


hmm guess I didn't know those exist?


changing to those immediately šŸ˜›


hmm neither has the necessary function for checking two ranges against each other


Yeah, but that function is just every? within some within every? within some. :)


On the other hand, neither of those two libraries seem to be well maintained, and there are some bad looking outstanding issues. But then again, node-semver seems to be in exactly the same boat... As an alternative, seems that you can use npm exec to run packages without having to install them - they will be fetched to an internal npm cache that won't interfere with anything, or at least it seems that way. The current CLI of node-semver doesn't allow for range intersection, but maybe it can be extended. At least this works:

npm exec --package=semver -- semver -r '1.0.0 - 2.1.0' 1.5.0


this really doesn't seem worth the trouble overall


I'll just remove it and pick the first one that is found


and just warn about others in case of duplicates


its not like thats any worse than what you currently get


One final alternative - you can use node to evaluate semver.js. If npm is installed, then node is installed, and I think it's possible to get its path reliably.


forking a node process has other issues though. thats why I didn't do that to begin with


again .. this is all not worth it. especially since it cannot be reconciled anyways in case of a real conflict


Ah, huh, alright. Is there a write-up of the issues somewhere, or maybe you could describe them in a sentence?


can't do anything anyways if something wants react v16 when something else wants react v17 but react v18 is already installed


Yeah, but if there is no conflict but multiple ranges and you get rid of semver.js, you can't do anything but keep on warning, right? Even if the ranges are perfectly fine.


there might be multiple :npm-deps declared dependencies that overlap or conflict. can only install one. which one do you pick?


thats the problem


could just trim down the version to something sane and compare that


What I mean is that one might require 1.0.0 - 2.0.0 and the other 1.1.0 - 1.9.0 while the installed version is 1.5.0. There's nothing to warn about, it's all consistent. But how can you check for it without semver.js?


ignore versions altogether and just pick the higher one


1.0.0 - 2.0.0 is not version range ever used in npm


so ^17.0.0 or whatever


just take out the ^ and compare against the other


if higher install that however it was originally


it never checks against an installed version


it really is just about the automated npm install for :npm-deps found in deps.cljs files


if its already installed nothing happens, regardless of version. that check was removed ages ago since it was never correct (ie. broken builds didn't warn, completely fine builds did)


the problem wouldn't exist if nobody used version ranges in :npm-deps but some do


actually some "did". haven't looked in many years what it looks like nowadays


How come npm does not use ranges, but :npm-deps allows it?


what do you mean? npm uses ranges by default all over the place?


> 1.0.0 - 2.0.0 is not version range ever used in npm


expressed in that format I mean


its always some shit like ^2.0.1 or ~2.0.1. I don't even know what these all mean and really don't care enough to figure that out


but there are more complex ones out there and those are the real problem


best option is probably to make this an interactive command


ie. shadow-cljs install-npm-deps or something


Ah, well - then my point still stands. :) Surely some JS packages use explicit ranges with both bounds. So if I understand you correctly, there are 3 approaches: ā€¢ Keep parsing and comparing ranges, via semver.js or whatever else ā€¢ Just install the highest version and hope for the best (but how will you know which one is the highest without parsing the ranges?) ā€¢ Install something according to one found version range and warn if there are other version ranges that aren't byte-for-byte the same


that on conflicts presents all options and asks for answer


yes, plus what I just said


In the case of an interactive command, it would put an extra onus on the user - and probably 90% of all users don't even need to run it, and another 90% won't even know about the command.


well it could just warn on startup if things are missing


"react was found as a declared dependency but is not install. please run npx shadow-cljs install-npm-deps." seems fine to me


Alright. Suppose I run that command and now nothing is missing. But then I add a new package that requires a completely different versions of already installed packages. You won't be able to warn about it, and I won't be able to realize that everything is broken.


that is fine. there is no check for this now. installed packages always win.


can't change this behavior either because thats the way you resolve conflicts


you install one that should win


can't just keep installing a newer version that the user may not want


there could also be a npx shadow-cljs audit-npm-deps


the problem really is just in trying to automate all this stuff too much


conflict resolution just needs input from the user to be resolved


the only feedback I ever got on this feature is "how do I turn off this warning"


> can't just keep installing a newer version that the user may not want Right, but could keep at least warn the user. It's an interesting difference in approaches, unless my knowledge is incorrect. npm just won't let you install something that doesn't satisfy the ranges unless you --force it. Maven/`deps.edn` will just resolve everything and use whatever's available, without complaining. The user will have to explicitly run a command to check if there are any conflicts.


npm install will install anything without any checks


if it runs into a conflict on transitive deps it will install them in nested folders


not resolving them at all


Eh, feedback is lopsided. Of course nobody will tell you "this warning is helpful, thanks for adding it". > npm install will install anything without any checks Uhm... Just a couple of weeks ago I couldn't install MUIv5 because of a conflict. I think it was requiring React 17 but some other lib really needed 16.


well maybe nowadays there are warnings. can't say. I don't use many npm dependencies anymore (really just one)


hmm yeah dunno. never saw that myself


gotta go. feel free to open an issue about this if you have suggestions or want to implement semver.js šŸ˜‰


> I don't use many npm dependencies anymore Heh, kinda ironic. But also enviable in a way. Yeah, will think a bit more about it first.


Oh, there might be a very simple and easy solution. You can concatenate versions with spaces, it won't break anything since there's only one binary operation, ||, and it has the highest precedence - the spaces are implied as &&. So something like >1 <8 >2 >3 || <1 is a valid version string. So: 1. Gather all :npm-deps 2. merge-with them with concatenating the version strings with spaces (replace empty versions with "*") 3. Add to those the contents of package.json, but only for dependencies that were in :npm-deps 4. Run npm install for every accumulated dependency with an explicit version If there are conflicts, npm will loudly fail. If there are no conflicts, the required dependencies will be installed, if they haven't been installed before.


though one issue is that older graal versions don't support the flag and will crash even if you bring in the script engine as a dependency and that would support this flag, been meaning to file an issue about this


Why am I not able to load source map?

DevTools failed to load source map: Could not load content for : HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE


status code 404 suggests that your :asset-path is likely wrong


oh wait. that is not a file from a shadow-cljs build?


so I guess the file is just missing?


The :asset-path is correct. The file is clearly missing, but I have no idea what is attempting to load it. What is supposed to generate that .map file?


I don't know. might be your html? might be something else you are including? this is not a file from a shadow-cljs build and as such shadow-cljs also wouldn't generate a .map file for it


OK, thanks.


has anyone encountered a similar warning?

Receiver reference in function ribelo.fatum.Fail changes meaning when namespace is collapsed.
Consider annotating @nocollapse; however, other properties on the receiver may still be collapsed.