How can I stop the ClojureScript compiler from resolving certain `require`s? - clojurescript

In my ClojureScript code I am requiring a JavaScript module called seedrandom which is in the node_modules folder, like this:
(ns something.core
(:require ["seedrandom" :as rnd]))
(js/console.log (.quick (rnd "x")))
According to the seedrandom documentation it is intended for both nodejs and the browser, and I've previously included and used it successfully in ClojureScript code via a <script> tag, confirming it works in the browser.
Running this cljs file in lumo on the command line works well and outputs a deterministically random number.
When I try to use this same cljs file in my Reagent frontend project I see the following error:
Compiling build :app to "public/js/app.js" from ["src" "env/dev/cljs"]...
events.js:183
throw er; // Unhandled 'error' event
^
Error: module not found: "crypto" from file /home/chrism/dev/something/node_modules/seedrandom/seedrandom.js
at onresolve (/home/chrism/dev/something/node_modules/#cljs-oss/module-deps/index.js:181:30)
...
Inside seedrandom.js we see the following:
// When in node.js, try using crypto package for autoseeding.
try {
nodecrypto = require('crypto');
} catch (ex) {}
Clearly this code is intended to ignore the built-in nodejs crypto module when running in the browser. The problem, as far as I can tell, is that the ClojureScript compiler does not know that - it sees that require('crypto') and tries to pull it into the compilation phase, but can't find it because it's a nodejs built-in.
Is there some way I can tell the compiler to ignore that particular require? Or can I shim the 'crypto' module somehow? What is the cleanest way to solve this?
Note: I have previously experienced this same issue with JavaScript modules which check for the fs node module. Hope we can find a general solution to use again in future. Thanks!
Relevant versions: [org.clojure/clojurescript "1.10.520"] and [reagent "0.8.1"].
This answer is related, asking a similar question from the perspective of Google Closure, which ClojureScript uses, but I'm looking for an answer I can use specifically with cljs.

Related

How to compile ES2018 javascript dependency?

I have a project with some NPM deps, noteably "#grafana/data": "7.0.1". These dependencies bring in several other libs like apache-arrow. When I try to require deps via (require '"#grafana/data"), I get a bunch of compiler errors like:
ERROR: JSC_LANGUAGE_FEATURE. This language feature is only supported for ECMASCRIPT8 mode or better: async function.
I found similar kinds of errors addressed in google closure compiler issues which leads me to beleive that I cant have library dependencies that require modern javascript as the closure compiler can't handle them. Similarly the closurescript docs don't allow for a :language-in argument for es-2018 et. al.
The the clojure build.edn settings I set are:
:language-in :es-next
:language-out :es5
:rewrite-polyfills
Unfortunately, this doesn't work.
Is there any way that I can get the closure compiler to handle modern javascript dependencies? Are there some crazy hacks that I can do to make this work?

Remove debugger keyword during compilation in google closure

UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
Im trying to find if there is a way to remove the "debugger" keyword during compilation process, im using the javascript version google-closure-compiler with gulp.
Looking through the documentation it is clear we can set the flag to stop/show error messages during compilation by doing the following.
https://github.com/google/closure-compiler/wiki/Flags-and-Options
--jscomp_off
translating this to gulp, it is:
const googleClosureOptions = {
...
jscomp_error:"checkDebuggerStatement"
}
however this works on stopping the compilation by throwing error or to show a warning.
zyxcdafg.js:1444: ERROR - [JSC_DEBUGGER_STATEMENT_PRESENT] Using the debugger statement can halt your application if the user has a JavaScript debugger running.
debugger;
^^^^^^^^^
but what I am trying to achieve is to remove the debugger keyword. Is this possible to achieve using googleclosure. I can not find any flags or options relating to this.
UPDATE:
The JS version of closure-compiler is no longer supported or maintained.
https://github.com/google/closure-compiler-npm/blob/master/packages/google-closure-compiler-js/readme.md
No I don't think so. I'd suggest you use something else to do it. Like sed:
find dist -name "*.js" -exec sed -i 's/\sdebugger;//' {} +
Something like that will find files in your dist folder that end with .js and then exec-ute sed to replace all instances of debugger; with nothing.
You could add that to a script that calls your Closure Compiler build.
The compiler doesn't have a command-line api for defining custom code removal passes, but the compiler's architecture does allow for registering custom passes and a pass to remove a debugger statement should be trivial:
if (n.isDebugger()) {
compiler.reportChangeToEnclosingScope(n);
n.detach();
}
The general structure would follow:
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/CheckDebuggerStatement.java

ClojureScript Eval. How to use libraries included in the calling code

I have a Clojurescript program running in the browser.
It imports a number of libraries, and then I want to allow the user to enter some small clojurescript "glue-code" that calls those libraries.
I can see (from https://cljs.github.io/api/cljs.js/eval) that you call eval with four arguments, the first being the state of the environment, which is an atom. But can I actually turn my current environment with all the functions I've required from elsewhere, into an appropriate argument to eval?
Update :
I thought that maybe I could set the namesspace for the eval using the :ns option of the third, opts-map, argument. I set it to the namespace of my application :
:ns "fig-pat.core"
But no difference.
Looking at the console, it's definitely the case that it's trying to do the evaluation, but it's complaining that names referenced in the eval-ed code are NOT recognised :
WARNING: Use of undeclared Var /square
for example. (square is a function I'm requiring. It's visible in the application itself ie. the fig-pat.core namespace)
I then get :
SyntaxError: expected expression, got '.'[Learn More]
Which I'm assuming this the failure of eval-ed expression as a whole.
Update 2 :
I'm guessing this problem might actually be related to : How can I get the Clojurescript namespace I am in from within a clojurescript program?
(println *ns*)
is just printing nil. So maybe Clojurescript can't see its own namespace.
And therefore the :ns in eval doesn't work?
Calling eval inside a clojurescript program is part of what is called "self-hosted clojurescript".
In self-hosted clojurescript, namespaces are not available unless you implement a resolve policy. It means that have to let the browser know how to resolve the namespace e.g. loads a cljs file from a cdn.
It's not so trivial to implement namespace resolving properly.
This is explained in a cryptic way in the docstring of load-fn from cljs.js namespace.
Several tools support namespaces resolving in self-host cljs running in the browser e.g Klipse and crepl

Using lodash module in babel-node REPL?

I am trying to test lodash, and apparently the following line won't work in the REPL:
import curry from 'lodash/curry';
See, e.g., babel-node es6 "Modules aren't supported in the REPL"
Why does babel-node not support module loading in the REPL?
Is there a way that I can pre-load a module like lodash into babel-node? (e.g. via a command line option or a configuration file)
If not, is there another way of evaluating ES6 with lodash preloaded?
So far, I've tried the online REPL at https://babeljs.io/repl/, and evaluation in the Console in Firefox. None worked.
import surely won't work, because the package should be installed first and bundled in order to be imported, which isn't the duty of Babel REPL.
Lodash is already loaded and used in Babel REPL, it can be used in REPL as _ global:
const { curry } = _;
If the question isn't limited to Lodash, the quickest way to get third-party library in REPL is to load the script manually. And since Babel website has jQuery loaded (as almost any website), the shortest way to do this is jQuery.getScript, in console:
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.js');
After that Lodash _ global becomes available in REPL.
The whole code can be wrapped with callback to skip console part:
$.getScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.4/lodash.js', () => {
console.log(_.VERSION);
});
babel-node REPL doesn't support imports, as the links in the original post say. Instead, require should be used, like anywhere else in Node.
var { curry } = require('lodash')
This requires to have lodash installed in node_modules that exists in current working directory.

TypeScript 'var' is undefined error

I built a console app to find all the *.ts files in my project and then compile them using tsc.exe.
Everything was working fine, but as I converted my JavaScript files to TypeScript, I eventually ran into the following error:
ytsc.js(21053, 17) Microsoft JScipt runtime error: 'window' is undefined
Each time this happened when I was trying to extend window:
window['prop'] = "something";
I tested the code until I found the answer, which had little to do with my code...
The fault was my build tool.
I had declared the -e (execute) command line option when calling tsc.exe:
I did this because I thought I might add some automated testing code in the modules.
The cause for the error:
Most of my code is in functions.
However, there were a few places that I wanted to extend 'window' (for example if a built in function is missing from an old browser, I was shimming those calls). The code to shim the window object was running as the file loaded:
if (window.fun == null) {
window.fun = function(){...};
}
Anyway, because of the -e option, the tsc.exe was attempting to run the code (outside of a browser environment). This caused the above error.