Project structure when using reader conditionals

[Colin Yates]

In the vein of "there are no stupid questions" :), how does one structure a combined clj and cljs project that uses reader conditionals? At the moment I am using cljx and have:

 - src/clj for clojure files

 - src/cljs for clojurescript files

 - src/cljx for cljx 

 - target/cljx/clj for clojure files compiled (transpiled?) from cljx

 - target/cljx/cljs for clojurescript files compiled (transpiled?) from clix

On the source path in cljsbuild for example I have src/cljs and /target/cljx/cljs

To remove cljx and use reader conditionals is it sufficient to:

 - replace src/cljx with src/cljc 

 - remove target/cljx from cljsbuild source path

 - add src/cljc to cljsbuild source path

 - add src/cljc to leiningen source path

Thanks!

[Robin Heggelund Hansen]

Take a look at my project.clj file.

https://github.com/Skinney/oslo-programmene/blob/development/project.clj

[Colin Yates]

Thanks Robin, that was helpful. I notice that you are using garden 1.2.6 - that throws a CNF for garden.core and the garden page recommends not using it - does it work for you?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robin Heggelund Hansen]

No, it doesn't. I update with `lein ancient update :all` and committed without checking if it worked. It's fixed locally :)

[Daniel Compton]

When porting a library to reader conditionals, I found that I only needed one source directory for all my cljc and .clj files. Cljsbuild just picks up the ones it needs and leaves the .clj ones.

So in some cases it may not be necessary to have a clj/, cljs/, and cljc/ folder, although in applications this structure might make more sense.

[Dru Sellers]

Is it fair to say that the accepted pattern now (with reader conditionals) is to have a single src/ directory and then letting the file extension (cljs,clj,cljc) do the heavy lifting rather than having a directory for each?

that would be handy if so. 

-d

[Alan Moore]

Yes it would be handy for small projects but IMO larger applications should be broken up into client and server code. Some might argue for breaking up client and server into separate projects altogether but that begs the question about what to do with the .cljc files that are shared (e.g. put them in shared library(ies)?) Again, this probably depends on codebase size, granularity of your deployment and other considerations beyond just the compiler.

For now I'm sticking with keeping the .cljc files in the src/clj tree. I'd like to hear what others are doing as well.

Did you ask this on the clojurians slack channel? It seems a lot of the more chatty/Q&A traffic for this list has gone over there.

Alan

[James Reeves]

My directory structure looks like:

    src/foo/client/bar.cljs

    src/foo/common/bar.cljc

    src/foo/server/bar.clj

So I divide code by purpose, but they're all in the same source directory.

- James

[Dru Sellers]

I was also playing around with a few different models. I was looking at something like client and server but probably over thinking it from my static type days:

These would just have needed bootstrapping code

src/apps/app1 - client app

src/apps/app2 - client app

src/apps/app3 - server app

src/features/<feature set 1>/bar.cljc

src/features/<feature set 2>/bar.cljc

etc

-d

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/PakgMNgczdQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Frank Castellucci]

Clean... very nice.

[Alan Moore]

+1

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/PakgMNgczdQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Dru Sellers]

I've attempted to catalog my craziness here, https://blog.eventgonegood.com/2015/12/26/project-structure/

[Matthew Boston]

I've done it multiple ways:

src/app/foo.clj

src-cljs/app/bar.cljs

src-cljc/app/baz.cljc

AND

src/clj/app/foo.clj

src/cljs/app/bar.cljs

src/cljc/app/baz.cljc

I prefer the latter, probably for ease of navigation in the command line and in emacs. But I totally agree that having them all together (src/app/...) would be nice. But I prefer to split up my "client", "server", and "shared" code. But now, you have me questioning if our notion of file paths and directories really are useful when structuring code. I recall an early argument for Light Table being against the notion of files and directories for structuring code.