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

Generic EDN config support #103

Open
ajoberstar opened this issue Jun 24, 2018 · 0 comments
Open

Generic EDN config support #103

ajoberstar opened this issue Jun 24, 2018 · 0 comments
Labels
area:clojurescript enhancement New feature or request

Comments

@ajoberstar
Copy link
Member

Desired Behavior

Provide a generic way for a Clojure-based task to accept dynamic configuration as a map, supporting additional EDN types: Keyword and Symbol.

Something maybe like:

interface EdnAdapter {
  put(Object key, Object value)
  put(Object key, Action<EdnAdapter> config)
  putIn(List keys, Object value)
  putIn(List keys, Action<EdnAdapter> config)
}

where usage would look like (rough take at it):

compiler {
  put(kw('optimizations'), kw('advanced'))
  put(kw('modules')) {
    put(kw('common')) {
      put(kw('output-to'), 'public/js/common.js')
      put(kw('entries'), [sym('sample.common')] as Set)
    }
    put(kw('cart')) {
      put(kw('output-to'), 'public/js/cart.js')
      put(kw('entries'), [sym('sample.cart'), sym('sample.shopping')] as Set)
    }
  }
}

It would be nice to get something cleaner than this. A couple challenges:

  • Keywords and symbol support. They aren't valid Java identifiers so you can't just do something like :stuff = 'things'.
  • Can't be too Groovy specific, since we would want this to work in Kotlin DSL too.

Context

Right now, the plugin has to statically provide every single option for any Clojure tool we call out to (e.g. ClojureScript compiler, Figwheel). Most of those tools accept EDN maps as config, and have a very dynamic sense of what can be provided in them.

For example, neither ClojureScript nor Figwheel document a :devcards option, but DevCards relies on a :devcards key to be in the compiler environment to decide whether to actually create the cards.

It is very difficult to provide support for these kinds of things, as there's always another option or another tool that will require more.

The major caveat here is that to leverage Gradle, we must still identify certain values as input files/directories or output files/directories. These are needed for Gradle's incremental build support to decide whether or not to re-run tasks.

@ajoberstar ajoberstar added the enhancement New feature or request label Jun 24, 2018
ajoberstar added a commit that referenced this issue Jun 26, 2018
Ideally, this wouldn't need explicit support, because we'd have to
continue adding options for every tool that leverages the compiler
options to do its work.

Long term solution will be addressed in #103.
ajoberstar added a commit that referenced this issue Jun 26, 2018
Ideally, this wouldn't need explicit support, because we'd have to
continue adding options for every tool that leverages the compiler
options to do its work.

Long term solution will be addressed in #103.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:clojurescript enhancement New feature or request
Projects
No open projects
Status: No status
Development

No branches or pull requests

1 participant