Thanks, and I’ve been putting off learning deps myself and figured might as well dive into using it since that’s where the wind is blowing. And you definitely can make your own modules with Kit. All you need to do is to create a git repo like this one, and then either add your repo under :modules in kit.edn or replace the official one entirely.
Ah, so this stuff is actually easier to do with this approach. With Leiningen you had to create plugins that work within the context of the build. However, however now all the tasks are tracked in build.clj, which is just a regular program. So now you can add a function that calls the library you want as part of the build. For example, this is what build.clj looks like in the demo app, and you could update the uberjar task to minify assets before the uberjar is created here:
A few prominent people in the community have been strongly advocating for using deps. Sean Corfield has written a lot about switching to deps. David Nolen and Alex Miller have been big proponents of it as well. I also notice that projects are starting to use deps. For example, Metosin is using deps for Malli now. While I personally like Leiningen, I do see the value of using the official tooling, and I think deps now reached feature parity with what Leiningen offers.
Remember the Clojure mindset: once it works, it always works.
Lein isn’t going away. I would consider lein going away to be a bad sign for the ecosystem as a whole. Just people are making more modern choices on NEW code, providing no pressure to update OLD code.
Congrats on the followup to a popular framework! I think this post has convinced me to start using the alternatives to lein in my projects.
Meanwhile I’ve written other code that I use heavily in my own work, my own framework you might say.
Could I end up using kit to manage my own modules?
Thanks, and I’ve been putting off learning deps myself and figured might as well dive into using it since that’s where the wind is blowing. And you definitely can make your own modules with Kit. All you need to do is to create a git repo like this one, and then either add your repo under
:modulesinkit.ednor replace the official one entirely.Cool!
So for deps, how would you replace something like https://github.com/yogthos/lein-asset-minifier in a way that could be seamless for my dep build?
Ah, so this stuff is actually easier to do with this approach. With Leiningen you had to create plugins that work within the context of the build. However, however now all the tasks are tracked in
build.clj, which is just a regular program. So now you can add a function that calls the library you want as part of the build. For example, this is what build.clj looks like in the demo app, and you could update theuberjartask to minify assets before the uberjar is created here:The docs show some examples and how to reference dependencies for the build in
deps.edn.I don’t suppose anyone can link to some material about the community’s inclination away from Leiningen and toward the core language tools?
A few prominent people in the community have been strongly advocating for using deps. Sean Corfield has written a lot about switching to deps. David Nolen and Alex Miller have been big proponents of it as well. I also notice that projects are starting to use deps. For example, Metosin is using deps for Malli now. While I personally like Leiningen, I do see the value of using the official tooling, and I think deps now reached feature parity with what Leiningen offers.
Remember the Clojure mindset: once it works, it always works.
Lein isn’t going away. I would consider lein going away to be a bad sign for the ecosystem as a whole. Just people are making more modern choices on NEW code, providing no pressure to update OLD code.