Heya, I have a problem using react-swipeable-views with shadow-cljs. When I go with yarn add react-swipeable-views it fails on the app start, giving me could not find module-entry: @babel/runtime/helpers/builtin/interopRequireDefault - most probably because that’s ES6 module. @thheller any clue on this one? I don’t want to use cljsjs lib for that.

ES6 modules have not been supported in the past, has that changed recently?

@piczmar.rss that is most likely caused by a dependecy conflict. es6 modules are supported just fine.

check the dependencies in node_modules/react-swipeable-view/package.json

@babel/runtime and which one is installed in node_modules/@babel/runtime/package.json

@clashthebunny ES6 modules have been supported for a long time

@marcinszyszko I think its just the usual npm nonsense. the file node_modules/@babel/runtime/helpers/builtin/interopRequireDefault.js does not exist

node_modules/@babel/runtime/helpers/interopRequireDefault.js does, so just without the builtin path. guess the path changed somewhere

gotta love npm 😉

@thheller could you help me with one thing that I did not understand well I'd like to build single :node-script that could be run without node_modules. I set {:js-provider :closure} but how to resolve built-in nodejs modules? like "fs" or "crypto"?

@maxp that is currently experimental. see https://github.com/thheller/shadow-cljs/issues/290

:js-options {:js-provider :shadow :keep-native-requires true} is what you need

is there something like lein-ancient for shadow-cljs to check the project dependancies need to be updated?

currently no

@thheller thank you very much. But I had to install bufferutil and utf-8-validate - that stuff used in try { require(...) } ... no workaround here?

hmm?

not sure what you mean?

there is such code in node_modeuls/ws/lib/BufferUtil.js `try { const bufferUtil = require('bufferutil'); module.exports = Object.assign({ concat }, bufferUtil.BufferUtil || bufferUtil); } catch (e) / istanbul ignore next / {

do you use the ws package?

oh right during development .. you probably want to add :keep-as-require #{"ws"} for development

since that won't be in release builds

still need to add that automatically

not me, it installed in dependencies. as I understand. may be clj-http required it

its shadow-cljs assuming you are using watch or compile?

I use shadow-cljs watch and shadow-cljs server

yeah just add :keep-as-require #{"ws"} then you should be fine

Great! it Works!

@thheller could you please explain to me how to add plain javascript file to the project build (not npm module).

https://shadow-cljs.github.io/docs/UsersGuide.html#classpath-js

thank you

if you can write the file in ES6 syntax though

commonjs has some issues

so import/export vs require

if some one interested in building 'single executable js' there is working example - https://github.com/maxp/rss2tlg

@thheller I’m trying to run shadow with lein profiles, but running into problems. When you use lien with profiles do I need to add shadow in lein dependencies? also even if I do that I still run into issues.

thats a dependency conflict on the closure-compiler dep

the way lein deals with dependency conflicts is by picking whatever comes first

so if anything has a dependency on clojurescript and thus closure-compiler it'll be picked

even if shadow-cljs depends on newer versions

so you need to resolve those conflicts

should be fixed by adding these deps

[org.clojure/clojurescript "1.10.520"]
[com.google.javascript/closure-compiler-unshaded "v20190325"]
[org.clojure/google-closure-library "0.0-20190213-2033d5d9"]

if you run through shadow-cljs.edn that is taken care of automatically

I’m not running the lein command, I’m running shadow-cljs just using lein with a profile to pull dependencies and paths (it’s really just for dependencies)

then you are using the lein command

or rather shadow-cljs is running it

when you use :lein ... in shadow-cljs.edn the JVM is launched using lein

so all its quirks apply

I see, yeah seem to be working now

The documentation says: “When executing directly via lein you must manually include the thheller/shadow-cljs artifact in your :dependencies. This is automatically added when launching via shadow-cljs.”

but I’m not doing that, so I found it a bit confusing that I needed to include shadow in the lien dependencies

I'm also confused what you are doing exactly 😛

Since we’re using lein ancient to check for updates, I didn’t want to rewrite it for shadow

also we still use lein to build the server side code

So I thought I’d just put the client deps in the lein profile and pull them from there with shadow lein config

so you are using :lein {:profiles ["foo"]} in your config?

nope

:lein {:profile “client”}

:profile is not a thing

what?

well regardless. IF :lein is a true-ish thing in shadow-cljs.edn

{:lein {:profile “+cljs”}

nvm. I thinking of deps.edn

that’s from the doc

yeah .. sorry got confused for sec

so :lein {:profile "+cljs"} means that when you run shadow-cljs watch thing

yeah

it'll execute lein run -m shadow.cljs.devtools.cli watch thing

basically

yeah

I saw that

but you need shadow in the lein dependencies for that

but it'll also run update-in [:dependencies] conj shadow-cljs or whatever the exact thing is

so no you do not need to add shadow-cljs

oh

IF you run through shadow-cljs

if you use lein normally it is better to add the shadow-cljs dependency manually

I still get: java.io.FileNotFoundException: Could not locate shadow/cljs/devtools/cli__init.class,

I ran: shadow-cljs compile app

watch is the same

which lein version do you have?

good question

2.7.1

hmm just add the shadow-cljs dependency

the inject might not work and isn't really all that reliable anyways

I'll check later

Ok thanks

https://github.com/thheller/shadow-cljs/issues/485

It all works when you add the dependancy

Might be good to think about plugin architecture so we can build stuff like lein ancient and the likes

no need for plugins

As far as I understand plugin at the moment are just for watch process

https://shadow-cljs.github.io/docs/UsersGuide.html#clj-run

shadow-cljs run some.lib/ancient

plugins are for things that need access to the runtime

ancient wouldn't need that at all

I'm going to build that eventually

time is a factor there 😉

it isn't much code to write that ... just something not high on my priority list

right

well it’s not really a plugin, just need access to shadow-cljs to read the dependencies key

it’s really just a slurp of a file

since it’s edn

well you can just (slurp "shadow-cljs.edn") and get :depdendencies yeah

just didn’t want to rerwrite the whole ancient code again

Or copy it 🙂

Got actual features to deliver!

Another question, does devtools from one build target impact the other?

I have http-port and http-root in test build target but it seem to apply also when I watch app build target

https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http

still supported in :devtools but yes they are all always started

since otherwise the HTTP server wouldn't be available if you used shadow-cljs compile foo while the server instance is running

I changed the config to make that more apparent

@thheller got it. Thanks for being super responsive, the clojure community needs more people like you.

The Clojure community also needs more people who allow people like Thomas to spend more time on their projects 🙂 http://patreon.com/thheller

Well I’ve tried googling but it wasn’t particularly helpful

Anybody know what to do when the (I’m guessing closure) compiler returns something like

Closure compilation failed with 1 errors
--- node_modules/vega-lite/build/vega-lite.js:8535
This code cannot be converted from ES6. extending native class: Array

I was trying to use Oz, and I think I was managing to install the (cljsjs) dependencies correctly (npm install vega-lite and then creating the namespace (

(ns cljsjs.vega-lite
  (:require ["vega-lite" :as vega-lite]))

(js/goog.exportSymbol "VegaLite" vega-lite)

@hobosarefriends maybe :compiler-options {:output-feature-set :es6} fixes it?

if you can live with es6 output that is

oh I tried :js-options {:language-out :ecmascript6}

I’ll give this one a whirl

@hobosarefriends try :output-feature-set instead, should be more reliable

okidoke trying that.

Well now I have another different issue, so I guess that worked

Thanks mate.

Is there a way to require a specific version of an npm package? (according to the package-lock I do seem to have both versions) in the namespace? (like :require ["[email protected]" :as vega-tooltip]