@thheller ok, great to know re: :lein true

are :js-options documented?

wondering the best way to handle something like this:

[:browser] Build failure:
errors in file: /Users/MattPro/Documents/sites2017/keys/node_modules/keypress/index.js
{:js-requires ["events" "string_decoder"], :js-imports [], :js-invalid-requires [], :js-language "es3", :js-errors [{:line 374, :column 30, :message "Octal integer literals are not supported in strict mode."} {:line 375, :column 30, :message "Octal integer literals are not supported in strict mode."}], :js-warnings [{:line 36, :column 3, :message "illegal use of unknown JSDoc tag \"api\"; ignoring it"} {:line 76, :column 3, :message "illegal use of unknown JSDoc tag \"api\"; ignoring it"} {:line 104, :column 3, :message "illegal use of unknown JSDoc tag \"api\"; ignoring it"} {:line 117, :column 3, :message "illegal use of unknown JSDoc tag \"api\"; ignoring it"} {:line 130, :column 3, :message "illegal use of unknown JSDoc tag \"api\"; ignoring it"}], :tag :shadow.build.npm/errors}
ExceptionInfo: errors in file: /Users/MattPro/Documents/sites2017/keys/node_modules/keypress/index.js

my current workaround is to include the keypress lib in a <script> tag and then a :js-option {"keypress": {:target :global :global "keypress"}}

interesting error, I’ll check it out

hmm that looks like a node package? are your building for the web or node?

web

oh wait

sorry

naming thing

var EventEmitter = require('events').EventEmitter; events is a node built-in

i thought this was a different library

there is a popular library called “Keypress” and I just assumed

hehe

:face_with_rolling_eyes:

keypress.js maybe?

that would be it

will add a formatter for that error

module without entry or suffix: keypress.js
{:package {:package-name "keypress.js", :package-dir #object[java.io.File 0x2e477178 "/Users/MattPro/Documents/sites2017/keys/node_modules/keypress.js"], :package-json {"name" "keypress.js", "version" "2.1.4", "main" "keypress.js", "description" "a robust keyboard input capturing Javascript utility focused on input for games. For details and documentation, please visit ", "devDependencies" {"jasmine" "1.3.0"}, "spm" {"main" "keypress.js", "ignore" ["compiler.jar"]}}, :version "2.1.4", :dependencies #{}}, :entry "keypress.js"}
ExceptionInfo: module without entry or suffix: keypress.js

i’ll try the react way

its one of those weird packages

"main" : "keypress.js", yet there is no keypress.js file in the directory, only a keypress.coffee

{:target  :npm
 :require "keypress.js/keypress-2.1.4.min.js"}

that works

exactly, I was about to suggest that

it exports an object with {"keypress": <the-fn>}

really something that should be done by the package but oh well

# Anonymous Module Definition
if typeof define is "function" and define.amd
    define [], ->
        return keypress
else if exports?
    exports.keypress = keypress
else
    window.keypress = keypress

(:require ["keypress.js" :refer (keypress)])

yup just did that and it works

https://github.com/dmauro/Keypress/issues/130 5 Dec 2016 still not fixed 😞

so string requires also work with the other cljs build tools - meaning i can switch all my libraries to (:require [“react” as react])?

yes they should

maybe out of scope, but is there a way to specify a fallback for the dev server? (eg. for pushstate routes, so /whatever/non/file/route returns index.html)

Reading about resolve in #cljs-dev I had the feeling that :type should default to :npm most of the time (convention over configuration they say?) - just an idea @thheller

@richiardiandrea :type? you mean :target? :resolve is optional, the default is to look up :npm. you only specify :resolve if you want to override something.

@mhuebert I could allow specifying a custom ring handler if required

humm. hinting externs..

(ns my.app (:require ["keypress.js" :refer [keypress]]))
(defonce Keypress (new (.-Listener keypress)))

new $module$node_modules$keypress_js$keypress_2_1_4_min$$.$keypress$.$Listener$; the referred keypress as well as Listener are renamed by the compiler & so it breaks

the only way I currently know how to get this working is pretty ugly:

(ns my.app (:require ["keypress.js" :as KP] 
                     [goog.object :as gobj]))
(defonce Keypress (new (gobj/getValueByKeys KP "keypress" "Listener")))

not sure how one could add hints somewhere here, or write an externs file that references things brought in from node_modules

@thheller cool that's exactly what I would expect 😉

@mhuebert try running shadow-cljs check browser with the first version

38 | (defonce Keypress (new (.-Listener keypress)))
-----------------------------------------^--------------------------------------
 Property keypress never defined on module$node_modules$keypress_js$keypress_2_1_4_min

otherwise create an externs.js file somewhere

/**
 * @externs
 */


/** @constructor */
var X = function() {};

X.prototype.Listener;
X.prototype.keypress;

then in the build config :compiler-options {:externs ["path/to/that-file.js"]}

Property keypress never defined on only this part is important

the property is unknown

i haven’t written externs by hand in awhile.. so X can be anything, doesn’t have to match module$node_modules$keypress...

yes, since CLJS is untyped X can be anything

but that “helps” us

X.prototype.keypress basically tells the compiler that whenever it finds some.keypress property access and it doesn’t know the type of some to not rename it

ie. https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/npm/externs.js

those are all the externs I use for the shadow-cljs script itself

shadow-cljs check is meant as a quick way to find things that need externs

btw not sure if you know that but shadow-cljs release browser --pseudo-names enables pseudo names to help debugging issues such as this

no need to fiddle with the config 😉

also shadow-cljs release browser --debug but source maps are currently not totally accurate once you use a JS dependency

still working out how to fix that

ah that’s a handy flag

--debug is --source-maps + --pseudo-names

I totally want to automate externs more … it should be possible to make it work automatically without additional config

just needs some work (and time)

anyways .. externs are not scary … don’t do this gobj/getValueByKeys 😉

I can totally fix the :refered names though. those should never need externs.

are there a lot of cases where externs files do more than list property names of the form you just showed?

it depends on the goals. in my cases never.

the Closure Library is fully typed, CLJS is not. so there are going to be cases where closure will be unable to infer the type of a thing

you can typehint all externs but that only benefits you if everything is typed

IMHO it is not necessary to typehint externs

so in many cases, a sufficient externs file could be generated from a vector of property strings

yes, in fact I should totally add that 😉

the problem with externs is that they may actually hurt

so if you have too many it might stop renaming things it could otherwise rename

say if you have (defn render [] ...) in CLJS, the render name would usually be renamed

but if you have render ANYWHERE in the externs it will not be renamed

even if you never have any native JS that has a render property

not yet sure what the best course of action is for externs

worst case is you keep a few extra KB of js if you have too many

yeah, and because these things are by definition repetitive, may not have a huge impact after gzip?

the problem is that it also stops DCE, not just the rename

so even if you never use render it will stay.

still should not be a huge impact, could always let someone write specialized externs

I will totally add support for an externs.txt, one string per line equals one property

never thought of that before 🙂

nice idea

afk, shopping

oh, i see.