This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-15
Channels
- # aatree (1)
- # atlanta-clojurians (3)
- # beginners (112)
- # boot (4)
- # boot-dev (1)
- # bristol-clojurians (1)
- # cider (55)
- # cljs-dev (23)
- # cljsjs (1)
- # cljsrn (7)
- # clojars (24)
- # clojure (84)
- # clojure-brasil (1)
- # clojure-china (1)
- # clojure-italy (27)
- # clojure-norway (17)
- # clojure-romania (1)
- # clojure-spec (109)
- # clojure-uk (92)
- # clojurescript (94)
- # community-development (1)
- # core-matrix (1)
- # cursive (12)
- # datascript (1)
- # datomic (23)
- # figwheel (1)
- # fulcro (17)
- # hoplon (11)
- # jobs-discuss (3)
- # keechma (6)
- # lein-figwheel (4)
- # leiningen (79)
- # lumo (32)
- # mount (42)
- # off-topic (22)
- # onyx (13)
- # parinfer (30)
- # portkey (47)
- # powderkeg (1)
- # programming-beginners (24)
- # protorepl (3)
- # re-frame (16)
- # reagent (100)
- # ring-swagger (7)
- # shadow-cljs (134)
- # spacemacs (3)
- # sql (1)
- # tools-deps (48)
- # uncomplicate (1)
- # unrepl (14)
- # yada (1)
I'm trying to migrate to shadow-cljs, but I keep getting this error:
module.js:478
throw err;
^
Error: Cannot find module '@cljs-oss/module-deps'
at Function.Module._resolveFilename (module.js:476:15)
at Function.Module._load (module.js:424:25)
at Module.require (module.js:504:17)
at require (internal/module.js:20:19)
at [eval]:3:13
at ContextifyScript.Script.runInThisContext (vm.js:25:33)
at Object.runInThisContext (vm.js:97:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:577:32)
at evalScript (bootstrap_node.js:351:27)
Does anyone have any idea on what may be causing it?
My package.json
:
{
"devDependencies": {
"shadow-cljs": "^2.2.9"
},
"dependencies": {
"create-react-class": "^15.6.2",
"react": "^15.6.2",
"react-dom": "^15.6.2"
}
}
shouldn't matter, I get the same errors when a module is not in node_modules dir, is this module there at all?
ok this is not a shadow-cljs dependency https://github.com/thheller/shadow-cljs/blob/master/packages/shadow-cljs/package.json#L30-L38 so you'll have to add this yourself, maybe you have cljsjs dependency that needs cljs-oss/module-deps.
Yes, it does. I think it has to do something with CLJS compiler itself. It tries to install the package here: https://github.com/clojure/clojurescript/blob/ade4ab7f8ab0fc1c74c627de7b042cf8b33beb14/src/main/clojure/cljs/closure.clj#L2340 And uses it here: https://github.com/clojure/clojurescript/blob/6b9c8c1aa8e9802314d8591d252bd0818d4e79e7/src/main/cljs/cljs/module_deps.js#L3
I forward this to thheller, I have a working shadow-cljs project and the folder (at)cljs-oss is not in my node_modules, so sounds strange.
Interesting. I just used re-frame-template
and modified the generated project to use shadow-cljs.
The shadow-cljs.edn
files do not differ between two projects. But the build for my main project starts with
Compiling ClojureScript...
Compiling ["frontend/static/js/main.js"] from ["frontend/cljs"]...
Options passed to ClojureScript compiler: {... A large map of options...}
[... the aforementioned error ...]
whereas the build for the generated project starts with
shadow-cljs - server running at
shadow-cljs - watching build :dev
[:dev] Configuring build.
[:dev] Compiling ...
I guess you'd only want to start leiningen for clojure (backend) stuff and leave the rest to shadow-cljs, icludeing removeing the cljsbuild from the leiningen plugins
Actually, I don't even use Clojure, I use Python. 🙂 I just wanted to try to migrate my project to shadow-cljs with the smallest cost possible.
ok, then use python to serve the output directories, you'll still get the hot-reload from shadow-cljs, if there's no clojure code involved, you don't really need leiningen anywhere.
Hmm, in the main project I have these lines:
;; to clean JS files generated during the build
:hooks [leiningen.cljsbuild]
Removing the last one also removes the error, which of course surfaces a whole bunch of other errors. But they should be fixable.@p-himik yeah I'd advice dropping lein
if you don't need clojure. the @cljs-oss/module-deps
is not from shadow-cljs
and must be coming from something in lein-cljsbuild
@thheller re: circleci, do you know if the issue with :jvm-opts
being passed down is a shadow issue or a deps issue?
cool, not a big rush, memory usage for my builds must be borderline because it works ~50% of the time. or maybe it depends on whether I’m sharing the instance with a crypto miner 💀
would i need to also put that in shadow-cljs.edn
, or does shadow run itself ‘under’ clojure
this is what i run to start the thing:
npx shadow-cljs clj-run maria.build/release;
shadow-cljs - config: /home/circleci/project/editor/shadow-cljs.edn version: 2.2.9
shadow-cljs - starting via "clojure"
should work in [email protected]
Suppose one project (say, reagent) depends on something from cljsjs (say, react). It has some particular version specified there.
Is there any way to automatically update this version in package.json
when the project updates its dependencies?
@p-himik cljsjs is not supported in shadow-cljs. npm is always used but no it is not synced until reagent starts declaring its react dependency via deps.cljs
:npm-deps
. I believe it started doing that in the latest alphas.
It's working! But I see some errors like Use of undeclared Var re-frame.cofx/kind
. The mentioned vars vary, but they all exist when I check. What could cause these warnings?
We don't need to (:require [some.thing])
in order to write some.thing/foo
, do we?
the :require
ensures that things get compiled in the correct order. without the require a namespace might be compiled before its dependency leading to those kinds of warnings
Interesting. I can't find any documentation on mentions without requiring, but I've seen a ton of examples from which I've learned.
shadow-cljs is a bit stricter for those things because of the more aggressive caching and parallel compilation by default
> parallel compilation by default
So one doesn't have to specify :parallel-build true
? Or is it something different?
:external-config
is dangerous with caching. handle with care. :closure-defines
not needed if all you set is goog.DEBUG
but otherwise yes
I use only :devtools/config
and :dirac.runtime/config
in :external-config
. Should be fine, right?
to be safe keep it in :dev {:external-config ...}
so it doesn't apply to release builds
I think the final bit in my project is to make dirac
work. In project.clj
I have :repl-options {:init (do (require 'dirac.agent) (dirac.agent/boot!))}
. Is it possible to have something like that with shadow-cljs
?
I found this in the documentation: "When enabled the watch will also hot-reload your code and provide a REPL." However, the link on "enabled" just goes to "Development Options" section that doesn't say anything about REPL.
OK, now I'm starting to think that I will still have to use Leiningen.
Because otherwise:
1. Apparently I won't be able to have some code being run automatically on nREPL connection
2. Cursive won't fetch any dependencies (or I'll have to generate pom.xml
each time shadow-cljs.edn
is changed)
3. I won't be able to use Leiningen plugins (e.g. lein-environ
) and tools (e.g. lein ancient
)
Also, attempting to use dirac
prints out something interesting:
[3:0]~shadow.user=> (dirac.agent/boot!)
#object[clojure.core$future_call$reify__8097 0x79c9b171 {:status :pending, :val nil}]
[3:0]~shadow.user=> -----------------------------------------------------------------------------------------------------------
[3:0]~shadow.user=> WARNING!
We detected unexpected middleware setup in your nREPL server at !
The difference (clojure.data/diff expected-ops reported-ops) is:
[nil
[nil nil nil nil nil nil nil nil nil nil :cljs/select]
[:clone
:close
:describe
:dirac-devtools-request
:eval
:identify-dirac-nrepl-middleware
:interrupt
:load-file
:ls-sessions
:stdin]]
For reference, the reported versions by the nREPL server are:
{:clojure "1.9.0", :java "1.8.0_151", :nrepl "0.2.13"}
This usually happens when some extra middleware gets injected into your nREPL server behind your back.
e.g. * Didn't you include a middleware via ~/.lein/profiles.clj or BOOT_HOME/boot.properties?
* Or maybe using Cider's nREPL stuff?
* Or maybe using some combination of ancient Clojure/Java versions?
* Or some bleeding-edge alpha versions?
* Or a rogue tools.nrepl dependency in your project or its dependencies?
Please follow Dirac installation instructions: .
-----------------------------------------------------------------------------------------------------------
I guess shadow-cljs
injects :cljs/select
, right?@p-himik should be harmless, you should be able to suppress that warning by passing a config overrides into boot!: (dirac.agent/boot! {:skip-dirac-nrepl-middleware-check true})
or something like that
there are maybe more warning suppression options, but it is not documented: https://github.com/binaryage/dirac/blob/46bd0ee54234d90240155c3df94b1946b7ecf182/src/lib/dirac/lib/nrepl_tunnel.clj#L312
How would one fully qualify a JS dependency when writing a macro?
@colindresj I have been thinking about that but the best solution right now is to create a helper fn in your cljs ns that calls the JS code and call that from the macro
Ok, that’s what I thought
Thanks
problem is that the JS namespace can change if filenames change or :browser
vs :node-script
Yeah, I was look at the compiled source and the references didn’t seem reliable
Don’t think a helper is the end of the world
you can get to it via the compiler env but I cannot guarantee that that won't change over time. so better stick with the helper fn for now
@thheller that is just a sanity check, people had weird issues when running some other middleware alongside dirac’s, just a warning
I might relax that check and check only against white-listed middleware which is known to be “compatible”
Just updated to shadow-cljs 2.2.10 and after first run I am receiving this error: https://pastebin.com/r0wteDyJ. Feels like a dependency issue but unsure. I am using ClojureScript 1.9.946.
@kenny use [org.clojure/clojurescript "1.10.145"]
thats the version now used by shadow-cljs. if you want to continue using 946 you must downgrade the closure compiler
Gotcha. Is there a compatibility table that has this info? Also, do you know if that is a stable release? The CLJS github doesn't have any visible info on that version.
technically you shouldnt worry about which cljs version you are using and just depend on the one shadow-cljs "ships"
there wasn't an official release yet since lots of the new stuff they were working on is not stable
While I'm here, ever since switching to shadow-cljs I receive this warning in the console:
Warning: It looks like you're using a minified copy of the development build of React. When deploying React apps to production, make sure to use the production build which skips development warnings and is faster. See for more details.
How do you include React in your builds? Right now it's just in my package.json
under dependencies
.It makes it sound like I should not be using a minified dev build of React when developing.
unfortunately due to their annoying packaging there is no way to get rid of the warning if you want to use the dev version
Unrelated note: Is there a way to get shadow-cljs to spit out the nrepl port into the same file leiningen uses so Cursive can work with the REPL? Right now I have to statically set the REPL port.
I haven't found a way in Cursive to set the nrepl port file to something other than the default -- .nrepl-port
at the root directory.
yeah I have been hesitant to write to that file since it belongs to lein and I don't want to get in its way
I mean in shadow-cljs. I'd think that If I explicitly specify shadow-cljs to write to .nrepl-port
then it becomes my problem if that interferes with lein.
maybe I can talk Colin into looking at other files now that shadow-cljs is gaining popularity
hmm
[2018-03-15 22:55:34 - SEVERE] spark/util/mongoose-types/lib/plugins/useTimestamps.js:1: ERROR - Invalid module path "goog:shadow.js.shim.module$mongoose" for resolution mode "BROWSER"
var mongoose = require('goog:shadow.js.shim.module$mongoose')
this is supposed to be a :node-script
, but this error says ‘resolution mode “BROWSER”’BROWSER
is the resolution mode for the closure compiler, we always use that since the others are just flat out broken
that was a cljs file attempting to require via a module via a relative path, which itself requires stuff from node_modules
ie. in my-namespace ["./util/mongoose-types" :as mongoose-types]
, and then in ./util/mongoose-types/
it requires other stuff
the file has var mongoose = require('mongoose')
which shadow-cljs replaces with the goog:shadow.js.shim.module$mongoose