tsc thinks it's a line break too, and fails with an unterminated string literal. I think what evalCheck is testing would still work if it were spelled "\u2029".

(I don't know if that cljs_env.js is coming from shadow-cljs or upstream; sorry if this is misdirected.)

this is coming from the closure library, nothing I can really change

can't you configure tsc to just ignore all the cljs output? I mean its not gonna find anything useful there?

okay, that's what I suspected. perhaps I can tweak the TS config to do the right thing.

it complains about missing imports if I delete the CLJS. but perhaps I can make it there-but-don't-check-it. anyway, it's out of scope here.

I actually already have a thread sort of about this. if you include CLJS output in a TypeScript build, tsc will fail to parse cljs_env.js. • the checks for which JS version is in use eval little fragments of JS to check what the engine supports: • the one for es_2019 uses a change to JS https://github.com/tc39/proposal-json-superset that added support for U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR as legal whitespace inside string literals, since JSON already does and JS is supposed to be a superset of JSON; this was a gap in that goal. • the eval'd code in that test has a literal U+2029 character in it

addNewerLanguageTranspilationCheck("es_2019", function() {
  return evalCheck('let r;try{r\x3d"
"}catch{};r');
});

hmm weird. I can't find the source of this psecific problem?

can you send me your cljs_env.js? wonder where it comes from

https://gist.github.com/bshepherdson/75353e47a89c1f845da9a6021fae296b line 718

I couldn't find where we got these checks from either.

ah it is no longer in the goog/base.js

but it is in the version currently used by cljs. so a bump in the closure library would take care of it I guess

ah, so this was patched by Closure?

yes, unfortunately bumping the closure library version has been less than reliable and often comes with a bunch of breaking changes

not sure we can seamlessy get a newer version. but this is something for #C07UQ678E I guess

maybe do start that question there again but mentioning goog/base.js instead of cljs_env.js

https://github.com/google/closure-library/commit/468188f4dc0d6fd756a142f2c7b72777fc0ebcb4

this was the commit where all the problematic code was removed

I mean if you want an immediate fix you can probably take this file https://github.com/google/closure-library/blob/master/closure/goog/base.js and put it in your classpath

hm. is there a clean way to force the version of the Closure compiler/library used by CLJS?

well, its just a maven dep. but there is no newer release as of yet as David does them.

I see. well, okay. this is definitely an obscure corner case, so a hack in the meantime seems appropriate. I'm tempted to just put a little script into our type-check command to change the character.

I asked if he can make a new release. shouldn't take long, until then manually copying is your ownly option

I mean why is this running through tsc in the first place? its never gonna do anything useful with it?

we're using tsc --noEmit to type-check the TS + JS + CLJS (output) codebase.

seems like it would speed things up if it would ignore it?

but what does that give you for the CLJS output? ever got anything useful from doing that?

if I exclude or delete the CLJS output it fails because there are imports in the JS and TS for things that don't exist. it doesn't really examine the JS files, but it does parse them.

hmm yeah I don't know anything about tsc, so not sure what to do here

I agree it's dumb, and that's why I'm fine with some hack like editing the file.

as I say, using the \u2029 escape fixes the outer parse without breaking the check it's trying to do inside eval, so that seems safe enough.

well we don't need any of the code that was deleted in the commit I linked

so just having it gone would best 😛

for sure. I'll follow the update and delete this hack once it lands.

give org.clojure/google-closure-library 0.0-20230227-c7c0a541 a shot. maybe that works out of the box. I'm deep in something else right now, so will be a bit before I test myself

just adding it as a dep should be fine

ah, cool.

it works. thanks! also as a bonus I realized this is probably why the line numbers and breakpoints have been weird and off-by -one in the devtools for this build.

because this literal paragraph break character confuses ~everything, including editors and Slack.

hehe. I don't know why it was there either or why the compiler replaces the \u variant. good that it is gone, it was useless code anyways

oh, I hadn't even spotted that in the commit. several parts of this code are encoded weirdly by the time it reaches the cljs_env.js on disk. it turns the = signs into \x2d or whatever the right ASCII code is.

fixing warnings is usually the best thing to do but I guess these libs might not be super maintained given https://github.com/thi-ng/math/pull/3

it would be great to be able to control whether they're printed

similar to how we can control which warnings are consider errors

I think only printing warnings from libraries once is reasonable

not like you are able to fix them anyways without restarting and changing the dependency

how do you use it in JS? what is logger in that example above? why is it set as a global? do you do that or does the library do that?

in JS:

SLLogger.log({
    "userType": "silver",
    "referralSource": referralSource,
    "campaignId": campaignId
  });

and what is SLLogger there?

The library. https://www.npmjs.com/package/sumo-logger/v/1.0.3?activeTab=explore

is there a const SLLogger = require("sumo-logger") or whatever?

I mean I'd expect (:require ["sumo-logger" :as sumo]) and (sumo/log #js {...}) to work

but thats just a guess

no const , it gets assigned to global var ( window )

but that global var has to come from something 😛

var logger = new SumoLogger();
window.SLLogger = logger; // default global logger

from var

ok, where is SumoLogger coming from 😛

I mean the code has to be loaded from something.

It is a function

function SumoLogger() {
    this.sendErrors = false;

…

(:require ["sumo-logger" :as sumo]) (def logger (sumo. opts)) (.log logger "event message to log", ...)

yes, but how do you get access to it 😛

var sumoLogic = require('sumo-logger');
    var opts = {
        endpoint: 'your HTTP Source endpoint',
        clientUrl: '' // NODE version only,
        // ... any other options ...
    };
    
    // Instantiate the SumoLogger
    var sumoLogger = new SumoLogger(opts);
    
    // Push a message to be logged
    sumoLogger.log('event message to log', {
      sessionKey: 'your session key value',
      url: ''
    });
    
    // Flush any logs, typically this line would be in your shutdown code
    sumoLogger.flushLogs();

It was js/SLLogger.log when it was still using library from CLJSJS

this I was looking for

so that translates to roughly the above

wait no it doesn't god these docs are trash 😛

thanks

var sumoLogic = require('sumo-logger'); I'm guessing thats just a mistake in the docs

otherwise the example still doesn't clarify where SumoLogger is coming from

but my snippet should still work

thats for node.js , it is different ( I am not using nodejs )

but you are using the npm package

yeah, sumologic has different version for nodejs env

ah

now I see it

> Add <script src="path/to/sumologic.logger.min.js"></source> or <script src="path/to/sumologic.logger.js"></source> to your pages.

yeah what a piece of nonsense that package is 😛

code is here https://github.com/SumoLogic/js-sumo-logger/blob/master/src/sumologic.logger.js

(:require ["sumo-logger/src/sumologic.logger.min.js"]) and then just the global js/SLLogger I guess

ok

uhm the first link you gave was to a super old version

which one do you actually use?

"sumo-logger" "2.5.5"

well yeah thats entirely different

(:require ["sumo-logger" :as sumo]) (def logger (sumo. opts)) (.log logger "event message to log", ...)

should be fine for that version

1.0 was definitely different