Thomas Heller
Thomas Heller
Most editors have a working nREPL implementation so it makes sense to tunnel shadow-remote over nREPL. As of `2.17.3` there are 3 new related nREPL ops to get full access...
Default `node` impl doesn't work since it assumes sync commonjs.
See - https://github.com/jkrems/proposal-pkg-exports - https://webpack.js.org/guides/package-exports/ - https://nodejs.org/api/packages.html#exports
I'm planning to deprecate the `:npm-module` build target since it is getting less and less reliable with each new Closure Compiler release and the world moving to more and more...
It is a macro which uses repl-env specific code which shadow-cljs does not have or use at all. Can't do `(pst)` after an error.
Keeps trying `(shadow/get-server-addrs)` instead.
Currently they are just logged once via `shadow.build.closure/log-warnings` but once cached they are gone. They are also kinda duplicated since `JSInspector` already runs into most of them and stores them...
There used to be a `(api/find-resources-using 'some.ns)` that at least would give you a hint how some namespace might end up in your builds. Ideally this is something directly integrated...
**WIP: everything here might change** `master` currently has support for a basic proof of concept for building [Chrome Extensions](https://developer.chrome.com/extensions) with shadow-cljs. The idea is to take a [manifest.edn](https://github.com/thheller/shadow-cljs/blob/master/out/chrome-ext/manifest.edn) which is...
Currently there are 3 separate passes that may emit code that requires polyfills. - shadow-js which converts npm sources - classpath-js which converts ESM on the classpath - goog-js which...