Fork me on GitHub
#shadow-cljs
<
2018-03-06
>
lilactown00:03:18

is there a way to use a different config file than shadow-cljs.edn?

lilactown00:03:15

(I'm trying to conditionally turn on :fs-watch {:watch :polling})

thheller08:03:56

@lilactown you can set it in ~/.shadow-cljs/config.edn. that config will be merged with the one in the project

thheller08:03:26

@hlolli thats a bug in shadow-cljs. just forgot to include the binding for REPL code. fixed in [email protected]

mhuebert12:03:32

I’ve just set up one additional module in my project, and am trying to understand the :module-move warnings (dozens of them now appear). The source says ;; only warn when a file is moved to a module it wouldn't be in naturally

mhuebert12:03:55

would you expect these warnings if, eg. following the guide, one creates an empty :shared module in order to collect common dependencies? then there would be no deps in :shared at all ‘naturally’

mhuebert12:03:14

or would there be something actually wrong, for this warning to appear

mhuebert13:03:24

hmm, after upgrading from shadow 2.1.4 to 2.2.4, I am getting a Cannot call a class as a function error at runtime:

shadow$provide.module$node_modules$graphql$language$source = function(g, v, m, r, l) {
    Object.defineProperty(l, "__esModule", {
        value: !0
    });
    l.Source = void 0;
    m("module$node_modules$graphql$jsutils$invariant");
    l.Source = function(a, f, c) {
        throw new TypeError("Cannot call a class as a function");
    }
}
;

thheller13:03:16

@mhuebert this is due to the newer closure compiler version. it was fixed recently but not released yet. https://github.com/google/closure-compiler/issues/2822

thheller13:03:47

you can downgrade the closure compiler manually by adding [com.google.javascript/closure-compiler-unshaded "v20180101"] to your deps

thheller13:03:03

@mhuebert yes :module-move is a bit tricky if you expected things to be moved

thheller13:03:48

its more about printing the information somewhere than a warning

thheller13:03:05

moving just means that your module structure might not be optimal

thheller13:03:28

generally it is not a problem though

thheller13:03:55

you can "fix" it by just declaring the namespaces that get moved as :entries for :shared

thheller13:03:30

there should be a better diagnostic than :module-move but thats what we have for now

thheller13:03:26

only warning it should print if an actual entry you specified gets moved because that might actually be a problem

mhuebert14:03:09

yeah it would make sense to see a message like “32 modules were moved”, and then that was written to a log somewhere

thheller14:03:42

yeah. moving can be non-obvious but it can be important

thheller14:03:59

usually isn't so the current solution is definitely too noisy