This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-12
Channels
- # babashka (37)
- # beginners (27)
- # biff (1)
- # calva (18)
- # cider (45)
- # clj-on-windows (5)
- # cljsrn (1)
- # clojure (90)
- # clojure-art (3)
- # clojure-uk (1)
- # clojurescript (7)
- # core-logic (4)
- # datomic (4)
- # events (2)
- # fulcro (3)
- # hyperfiddle (23)
- # leiningen (66)
- # malli (1)
- # meander (7)
- # nrepl (1)
- # off-topic (9)
- # pathom (1)
- # re-frame (15)
- # reitit (19)
- # remote-jobs (1)
- # shadow-cljs (103)
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?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
so I guess the re-highlight
has one and removing that will not cause that part of the code to run
setting :npm-deps {:install false}
in shadow-cljs.edn
should also get rid of the warnings
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 😛
One caveat - it will be harder to update once SemVer inevitably becomes 3.0.0 or even 2.0.1.
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=
.
Actually, this raises a question - why didn't you use https://github.com/vdurmont/semver4j or https://github.com/zafarkhaja/jsemver?
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
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?
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
?
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)
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
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
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.
"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.
> 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.
if it runs into a conflict on transitive deps it will install them in nested folders
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)
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.
Created an issue: https://github.com/thheller/shadow-cljs/issues/998
the warning is there when running on graal. @p-himik can also be set programmatically https://github.com/nextjournal/viewers/blob/main/modules/markdown/src/nextjournal/markdown.clj#L22
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
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?