org.clojure/data.json 2.2.3 is now available • Fix https://clojure.atlassian.net/browse/DJSON-47: Make number parsing match spec (reject invalid numbers) - thanks to @nbtheduke!
com.github.seancorfield/honeysql {:mvn/version "2.0.0-rc1"}
— SQL as Clojure data structures. Build queries programmatically -- even at runtime -- without having to bash strings together. — This is the first Release Candidate for the 2.0 version, which has been in development for about seven months and has been tested by various people for a few months now (in production). This contains two small bug fixes and one new formatting option, compared to Beta 2. https://cljdoc.org/d/com.github.seancorfield/honeysql/2.0.0-rc1/doc/getting-started Follow up in #honeysql Thanks to @snorremd and @dharrigan in particular for diligent testing and finding bugs!
Wow, I didn't realize there was a HoneySQL 2.0 in the works. It looks great! After reading "Differences Between 1.x and 2.x", I have a couple questions:
* Is setting :quoted
the only way to toggle snake_case conversion? That feels like a complection that will come back to bite us later.
* It's a little silly, but I have a personal vendetta against the words "helper" and "util" in namespaces due to their vagueness. Did you consider honey.sql.builders
or just honey.sql.build
?
@michael348 HoneySQL has had a helpers
namespace for many, many years — V2 simply matches V1 on that (although it’s honey.sql.helpers
vs honeysql.helpers
).
I’m not sure what you mean about :quoted
toggling snake_case?
I know v1 had a helpers
ns, I just wanted to bring it up since this is the only chance to choose something different. Anyway it's just my own sense of aesthetics, so I'm not going to try to push on that
on the other point, perhaps I misunderstood this line from the v1->v2 guide:
:allow-dashed-names? -- if you provide dashed-names in 2.x, they will be left as-is if quoting is enabled, else they will be converted to snake_case (so you will either get "dashed-names" with quoting or dashed_names without).
During the alpha releases, the namespace could have been changed. Once it hit beta, only accretive/fixative changes were being made. So that ship sailed over a month ago.
fair enough
I guess you’re not in the #honeysql channel? This stuff has been discussed there over the past few months as folks have been testing the alpha and beta releases.
no, I'm not— sadly we're not using HoneySQL at my current shop so I hadn't been following it. Thanks for the pointer; I'll go look at the archives
No one has raised any concerns about the dashed names issue so far — beyond V1 being far too complicated in that area 🙂
new syntax for :array :cast :inline etc is wow as useful!
Just cut the first snapshot of com.teknql/shadow-cljs-tailwind-jit
- introduces management of Tailwind's stylesheet JIT watch / release process into shadow as build hooks. Helps you to avoid having to pollute your repo with a postcss.config.js
and tailwind.config.js
boilerplate (still relies on you having a package.json, but that seems fair enough in most cljs projects). Early early release but if anyone wants to give it a spin: https://github.com/teknql/shadow-cljs-tailwind-jit
What are the main differences from https://github.com/jacekschae/shadow-cljs-tailwindcss?
Ah, you're using hooks whereas that project uses npm run
.
great question! That repo is an example of running tailwindcss-jit alongside shadow. It works by using npm run dev
to start both the shadow process and the tailwind process. Your project is expected to have the required config files (ie. tailwind.config.js
, postcss.config.js
, and a boilerplate src/css/tailwind.css
). My project generates those files for you based off of config in your EDN (ie. you can have a :tailwind/config {...}
in your shadow file, and then shadow's build hooks take care of maintaining a side-car process that manages a temp directory with the required boilerplate that then outputs to your project directory. The end result is that it feels less like a node project and more like a shadow project. It also has the benefit that most editors know how to cider-jack-in
(or their equivalent) to a shadow project, while starting a project via NPM would require additional config
Thanks for the detailed answer!
io.github.cognitect-labs/test-runner v0.2.0 is now available (as a git dep) • Fix #12 - fix reflection warning • Fix #17 - mix of -n and -r should work • Add #26 - use exit code 1 when args are invalid • Add #17 - skip fixtures if no vars from test ns are being run • Add #28 - add entry point for -X style invocation • Bump deps to latest + clojure 1.9.0
A bit off-topic, but shouldn't http://cognitect-labs.github.io have some info about test-runner?
Maybe it should just be promoted as the official test runner on http://clojure.org?
Or somewhere in the deps / CLI guide
It’s not an “official” test runner
But it could be promoted to be one
@vlaaad it should! I didn’t realize that page existed
@vlaaad added (and a lot of other cognitect-labs projects). turns out I created that page, but have no memory of doing so. :)
I don't think an official test runner even makes sense if it is just another dependency anyway.
@nilern Don't you think mentioning this as a "go to" solution for deps.edn-based projects in the Deps and CLI guide would be useful?
I do, I actually thought it was in there
It’s mentioned on the t.d.a wiki https://github.com/clojure/tools.deps.alpha/wiki/Tools but I don’t see it mentioned anywhere on http://clojure.org
there are a few more outstanding issues/prs on the repo, I'll get to those the next time I take a pass here. let me know if I broke anything. I gave this release a tag and will continue to do that in the future so there is some sort of human version beyond the sha.
This is a great tool, thanks for refreshing it!