Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard to set the figwheel configurations #5

Open
zerg000000 opened this issue Jun 20, 2017 · 3 comments
Open

Hard to set the figwheel configurations #5

zerg000000 opened this issue Jun 20, 2017 · 3 comments

Comments

@zerg000000
Copy link

Currently, the the figwheel configuration will be generated by figwheel-config

(defn- figwheel-config [path main]
  {:duct.server/figwheel
   {:css-dirs ^:displace ["resources" "dev/resources"]
    :builds   ^:displace
    [{:id           "dev"
      :figwheel     true
      :source-paths ["dev/src" "src" ]
      :build-options
      {:main       main
       :output-to  (str path "/js/main.js")
       :output-dir (str path "/js")
       :asset-path "/js"
       :closure-defines {'goog.DEBUG true}
       :verbose    false
       :preloads   '[devtools.preload]
       :optimizations :none}}]}})  

which is hard to change like ':figwheel {:on-jsload "..."}', the only option is to override all the figwheel config.
when people needs multi builds (e.g. js per page, serverside rendering specific js) for development would be really hard to change the config.

Currently, I could only hard code all the configs under :duct.server/figwheel and :duct.compiler/cljs. It is not ideal, since the path and main would be hard-coded.

Would it be any better way to do it? like the boot-reload, .cljs.edn?

@weavejester
Copy link
Contributor

I was considering making :builds take a map, making it easier to override in the configuration itself. So you could write:

:duct.server.figwheel
{:builds {:main {:figwheel {:on-jsload "..."}}}}

But that functionality relies on me releasing duct/core 0.5.0 first.

Another thing I've been playing around with is to put common options in the module itself, but I haven't decided how that will take shape.

What do you mean by "like the boot-reload, .cljs.edn"?

@zerg000000
Copy link
Author

https://github.com/boot-clj/boot-cljs/wiki/Usage

boot-cljs and boot-reload use individual build infos in .cljs.edn in the resource path, each contains map like this

{:require  [foo.bar baz.baf]
 :init-fns [foo.bar/init baz.baf/doit]
 :compiler-options {:target :nodejs}}

so the cljs compiler and cljs reloader could guess the output path from the .cljs.edn location and share the same piece of build info

@weavejester
Copy link
Contributor

Ideally we don't want any piece of configuration outside Integrant, as then we lose all the benefits of modules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants