I'm guessing its a ESM/CJS interop issue, see https://clojurians.slack.com/archives/C6N245JGG/p1706896359632389

solution at the end might be the same

but I suspect that the code will end up relying on features shadow-cljs does not support, such as bundling fonts or css

I suspect that they expect you to be using the vercel platform which would take care of this

you could just take the actual font files and use them in your page via css

https://nextjs.org/docs/app/building-your-application/optimizing/fonts

yep, thats not something shadow-cljs does

The font page seems to have instructions for non-nextjs projects (plain react with tailwind), thats why I thought it could work

Let me try the above and I'll check back

just "Get the .zip"

take the zip, put it into a http reachable folder (e.g. "public/css") and add a css file to include the fonts. you can use this css file as a reference

https://cdn.jsdelivr.net/npm/[email protected]/distr/fira_code.css

just need to swap those file name references with the geist font names

using this font as a reference https://github.com/tonsky/FiraCode

works exactly like any other font

without any JS

Yep I know that in the end this is the proper solution

I'm just experimenting on how far the js interop goes

the font itself has no code, only what I guess are "markers" for the next platform to do its thing

Ok I just tried

:target-defaults
 {:browser
  {:js-options {:entry-keys ["module" "browser" "main"]
                :export-conditions ["import" "module" "browser" "require" "default"]}}}

I tried with

:target-defaults
 {:browser
  {:js-options {:ignore-exports true}}}

(Just to be clear, I'm not really interested in adding this font to my playground project, I'm just trying to find out why this specific npm package does not work, in order to learn how to debug this kind of stuff)

well you are debugging a package that has no actual JS in it

https://unpkg.com/[email protected]/package.json

this file uses "exports", so by setting :ignore-exports you are ignoring them

Are you sure it has no js? https://github.com/vercel/geist-font/blob/main/packages/next/dist/font.js

and the fallback then cannot find font/sans in that package

this is the JS file you get for geist/font/sans https://unpkg.com/[email protected]/dist/sans.js

the problem itself is in this package "next/font/local"

and if you follow that along you end up with this file

https://unpkg.com/browse/[email protected]/font/local/index.js

this is empty

and as I suspect serves only as a marker for the next/vercel platform tools

it at the very least does not have a localFont default export

which is why you are getting the error

Very insightful deep dive

shadow-cljs is following this all along, there is just code missing. everything else worked as its supposed to

I understand now why it breaks

But my question now is why it works in js in the first place

How is the localFont fn defined?

it doesn't work

like I said. I suspect that vercel is providing special support for this during compilation

Ah yeah that makes sense

which the article I linked seems to suggest

the compiler then replaces this call with something else I guess

Thank you VERY much for the explanation

It was a nice dive

Keep up the fantastic work with shadow-cljs!

I wish I understood why JS people have to add stuff like this 😛

I know, the ecosystem is already really badly stitched with lots of awful stuff

Then you have this on top of it

run the build with npx shadow-cljs release <your-build-id> --pseudo-names to identify where this eval is from

kinda hard to tell otherwise

I'll do it

shadow-cljs or closure do not put eval in your code, so it is coming from other code you are using

it seems nothing changed

oa=function(a,b,e){oa=Function.prototype.bind&&-1!=Function.prototype.bind.toString().indexOf("native code")?caa:daa;return oa.apply(null,arguments)};ra=function(a,b){var e=Array.prototype.slice.call(arguments,1);return function(){var g=e.slice();g.push.apply(g,arguments);return a.apply(this,g)}};ta=function(a){(0,eval)(a)};

from package.json:
{..."build:release-static": "npx shadow-cljs run dev.build/build-release-static --pseudo-names",...}

(defn build-release-static []
  (clean-compiled-resources)
  (export-image-assets-and-replace-paths)
  (export-deeplinking-assets)
  (shadow/release environment {:verbose true})
  (compile-sass)
  (export-assets)
  (index-csp))

well if you are building like that the option won't apply

just run the regular release command, you don't need all this extra stuff just for debugging this

or change to (shadow/release environment {:verbose true :pseudo-names true})

$goog$globalEval$$ = function($script$jscomp$1$$) {
  (0,eval)($script$jscomp$1$$);
};

ok, do another search for where $goog$globalEval$$ is used

if ($JSCompiler_StaticMethods_evaluateCode_$self$$.$sourceUrlInjection_$ || $JSCompiler_StaticMethods_evaluateCode_$self$$.$debugMode_$ && ($goog$userAgent$product$CHROME$$ || $goog$labs$userAgent$browser$matchFirefox_$$() && 0 <= $goog$string$internal$compareVersions$$($goog$labs$userAgent$browser$getVersion$$(), "36"))) {
      for (var $i$jscomp$165$$ = 0; $i$jscomp$165$$ < $uris$jscomp$4$$.length; $i$jscomp$165$$++) {
        $goog$globalEval$$($texts$$[$i$jscomp$165$$] + " //# sourceURL\x3d" + $uris$jscomp$4$$[$i$jscomp$165$$]);
      }
    } else {
      $goog$globalEval$$($texts$$.join("\n"));
    }

ok, now generate a build report via https://shadow-cljs.github.io/docs/UsersGuide.html#build-report

as in this example report you'll find a group for org.clojure/google-closure-library https://code.thheller.com/demos/build-report/ui-report.html

expand that and look for goog/labs/userAgent I guess

if you mouseover that it'll tell you what end up including that

I have a suspicion

let me check the code. I was not aware there is eval in it

ok

trouble is that its kinda hard to identify what this code actually was before optimizations

you can try finding //# sourceURL in the source code prior to optimization

so for example from a dev build in its cljs-runtime folder

shouldn't get too many hits

ok

do you use multiple :modules?

4

yes

hmm yeah that might be it then. the loader dynamically loads modules and evals them potentially

so, what's the ways?

good question. I don't think there is one

🤕

I mean I guess you could switch to using :target :esm and use esm instead

how are you loading the modules in the code?

I thougth it is internal from shadow, rigth?

if you are using shadow.lazy then yes

I only use this in config:

...:modules           {:base      {:output-to  "resources/public/js/compiled/base.js"
                                               :init-fn    core-client.core/init}
                                   :checkout  {:output-to  "resources/public/js/compiled/checkout.js"
                                               :entries    [checkout.core]
                                               :depends-on #{:base}}
                                   :site      {:output-to  "resources/public/js/compiled/site.js"
                                                :entries    [site.core]
                                                :depends-on #{:base}} ....

those :output-to do absolutely nothing, so you can remove them

do you also set :module-loader true?

yes

or use shadow.lazy, shadow.loader, cljs.loader in your code?

ok thats is what is causing the problem

module-loader

thats why I'm asking how you are loading the code

do you actually use any of the above namespaces in your code?

or do you just load the files manually via HTML?

is there any code loading checkout.js dynamically I mean?

I only load the base.<hash>.js and use the namespaces.

into html

so you are not dynamically loading any modules in your code?

no

how/where is checkout.core used?

if you are not loading the modules dynamically then you do not need :module-loader true

sorry, I use shadows.loader

hmm yeah that is the problem then

shadows.loader call eval?

indirectly yes I guess

so, what is the solution for that?

you can try one thing

copy this file into your source files

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/loader.js

so src/main/shadow/loader.js or so

after this line https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/loader.js#L17

add ml.setUseScriptTags(true);

maybe thats enough to get rid of the eval parts. I guess the defaults use eval

goog.module.ModuleLoader is the actual thing doing the evals

https://github.com/google/closure-library/blob/master/closure/goog/module/moduleloader.js#L354-L380

that being the problematic code

yes, I see

so, if you could help me to understand right: copy the loader.js to source code (where?), and include this ml.setUseScriptTags(true); in that line you told?

is there any change do I have to fix in compile process?

where do you keep your sources? src or src/main?

src/cljs

ok so create the src/cljs/shadow folder and put the linked loader.js in it

that will make shadow-cljs use that file over the file it ships itself

thus you can add the line above to it to test if this actually fixes the problem and ends up removing the eval

no further changes required, just do another release build and see it eval is still in it

the intention is that the goog.module.ModuleLoader appears to have two separate loading mechanisms, one using eval one using script tags

script tags might not require unsafe-eval

I'm debugging with you, I never had to deal with the CSP restriction and I suspect no one else has

so just testing if this can work

if it works I can add an option for this so you don't have to do this manual patching

that's amazing man, thank you very very much

first need to find out if it actually works though

I'm doing it

so the compiled code should remove the $goog$globalEval$$?

I included the source "loader.js" and included that line

assuming thats in the src/cljs folder then it looks correct

we are testing whether this removes the eval or not, I thought that it might. if the above doesn't work then I guess it does not.

so, I have to deploy to see if is it work?

you should be able to tell by looking for eval in the new output?

dunno if a full new deployment is necessary. if eval is still there it'll likely fail for the same reason

I'm still seeing the

$goog$globalEval$$ = function($script$jscomp$1$$) {
  (0,eval)($script$jscomp$1$$);
};

hmm dammit

I actually don't know if CSP actually already fails when it sees eval, or only when you actually try to eval?

if its the latter it may actually work

(don't forget to remove the :pseudo-names btw, that was only for debugging)

I'm running in CSP report-only mode, but if it catches it as eval , browser will not permit runs the eval

as far as I can tell if won't try to eval when using script tags

so might be worth trying I guess

you can try adding console.log("actually set to use script tags") in the loader.js file, just to verify this hack actually worked

yes, the system have an event that calls shadlow.loader , that is the time it's been reported

console.log("actually set to use script tags") -> where?

yes, prior to this change it would have definitely used eval, the question is if it still does

anywhere in shadow/loader.js

just want to verify that this file is actually getting used over the default

should I see this message where? In compile process?

in the final output by searching for it or at runtime, not during compilation no

sorry, long process to run the system locally

worked -> actually set to use script tags

so, at this point , will it runs ok?

maybe it's depends the setUseScriptTags

I do not know. I cannot answer this. you need to check if it runs

well, it seems that the new loader.js runs

so no more CSP errors?

I have to deploy to qa environment that has all the csp rules for checking

I'll do it and tell ok? thank you

I'm still using "shadow-cljs": "2.15.3", is that a problem?

I don't think so, because it's 3 years old file

that shouldn't matter

Hello @U05224H0W , It does not work

it's complaining about the eval stuffs

{
    "csp-report": {
        "document-uri": "https://*******/****",
        "effective-directive": "script-src",
        "original-policy": "...",
        "blocked-uri": "eval",
        "line-number": 1903,
        "column-number": 322,
        "source-file": "https://*******/js/compiled/base.ABCF3918963DA671CD471DB45FB2D01D.js",
        "status-code": 200
    }
}

hmm then I guess your only option is switching to :target :esm and then restructuring a bit to not use :module-loader true and shadow.loader

ok, I'll do it, do I have to use both or first try removing module-loader?

well, removing module-loader but keeping the lazy loaded functionality requires going :esm

you can remove the multiple modules, but I suspect you want to keep this

so the main change is for :taget :esm?

I don't know what you mean by that question

I haven't seen your full build config

it could just be switching :target :browser to :target :esm

test removing :module-load true and :target :esm ?

well, your code will then fail if its still using shadow.loader

but yes, that is step one

the compiling failed with :target :esm

that fails in your code, not something I can debug for you. dev.build is not part of shadow-cljs

humm, I'm using version 2.15.3 . Is there a problem with that version?

no. I repeat this is failing in code that is not part of shadow-cljs, it has never existed in shadow-cljs. It is your code that is failing. I cannot say why it is failing.

run npx shadow-cljs release app, if that fails I can help you. otherwise you are on your own

yep, something here

it said that the manifest.edn was not created

ok. that is a :target :browser only feature, :target :esm does not create that

hummm, I use that files to read the main js with hash to inject into index.html

it seems that the :esm does not create the modules with hash in .js file names

:module-hash-names is also a :target :browser only feature, that is correct

I usually recommend people don't use that, even for :browser

well, it's a feature that is working 4 years

so, is the :esm the solution or a guess? Should I remove the shadow/loader too?

and use dynamic-import?

the simplest solution to me is allowing unsafe-eval, but you seem to have reasons thats not possible

you must remove shadow.loader yes, that is the source of your issue after all

yes, I'm implementing the CSP rules for security reasons

well you could still allow if for your sources, and just disallow it for others

you mean include all the modules into script-src ?

your domain

well, I'm using 'self' as the rule

but the eval is not allowed

then :esm it is I guess

what is the propose of scriptTag? Do something like inject a <script> ..... Module .... </script> ?

yes, regular old JS doesn't have a standard way of fetching additiontal JS dynamically. so the goog.module.ModuleLoader will either fetch the code via XHR and then eval it

or add a script tag and load it that way. that way should not require eval

with ESM you can just do a dynamic require to load the code, supported by the browser natively

but you cannot use dynamic import to load a :browser module dynamically, since the rules for ESM are different and as such the output won't work

yes, that's I'm thinking

so, only works if everything is ESM from the start, meaning :target :esm

Hello @U05224H0W,how are you?

I could solve the problem with eval loading, replacing the shadow.load

which route did you go?

I uses inject script tag into header

so, one thing, how do you convert the keyword to js path? In load function

I do not understand that question. what load function?

shadow.load

this function receives the keyword defined into shadow-cljs.edn modules

like here

:modules           {:base      {:output-to  "resources/public/js/compiled/base.js"
                                               :init-fn    client.core/init}

the compiler injects this data into the build when :module-loader is true

:output-to has no effect there, you can remove that

ok, but where is this mapping injected?

what do you intend to do with it? I'm asking because this is all strictly for shadow.loader, if you are not using that you are not supposed to use that data

so start with what you are trying to do instead, then I can make suggestions

for using the script tag aproach I have to know the filename of .js files. I have to use the hashes in the filenames because of caches. So, to this new module loader I wrote, how can I get the files if it will be dynamic because of hashes?

I'm thinking use the module-loader.edn to read all the references

if by assert you mean :pre when yes, those are removed by default for release builds

you can set :compiler-options {:elide-asserts false} to keep them

I don't see the :pre keyword but the macro has the form

(defmacro thing
  ([args]
    (assert ...)
    ...))

Is that the same thing?

hmm I guess I didn't understand the question

that assert should still fire, given that its in the macro, not the emitted CLJS code

Is this related? https://clojurians.slack.com/archives/C03S1KBA2/p1707239220487469

hmm actually thats correct

https://github.com/thheller/shadow-cljs/blob/defd998d26bdb6050875a86f66aeb113f4b33374/src/main/shadow/build/compiler.clj#L724-L725

If I wanted to balance correctness checks and performance, would it possible elide CLJS asserts but maintain CLJ (macro) asserts?

(in this case I have a fairly complex macro that can be easily misused)

just don't use assert in the first place

You'd have to write assertions without "assert"s

it makes absolutely horrific error messages that are basically impossible to debug

just throw an exception instead

"assert" by my definition are "this must not happen, if it does the world is allowed to explode"

they are not for "hey, you provided an incorrect input"

I'm technically not against changing how *assert* is bound, but the CLJS compiler will bind it like that too

since asserts work so differently and are so easy to toggle, sadly many people have many different interpretations

I definitely want to break the build in the case that this assert fails on any code written, so I will follow your advice and dump the assert and just throw

I agree the semantics are a bit vague now that I actually think about all of this

Thanks very much, both of you!