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

Cojure CLI - designing aliases #426

Open
practicalli-johnny opened this issue Aug 17, 2022 · 3 comments
Open

Cojure CLI - designing aliases #426

practicalli-johnny opened this issue Aug 17, 2022 · 3 comments

Comments

@practicalli-johnny
Copy link
Contributor

If you always have the same setup, then one alias with everything can be the optimal approach

An aliases that has everything is fine. The only constrain is that it will alway run everything. The alias may use up a little bit extra memory and slightly slower startup times (but it's rare that this would be noticeable at development time)

Aliases main role is to separate development (or testing) configuration & tools from production. This helps keeps the generated application (uberjar) smaller and faster to load in production

Aliases allow for the definition of specific development task, e.g :test/watch to run kaocha test runner every time a file is saved

Extracting common configuration is more useful in a user configuration (e.g. ~/.clojure/deps.edn.
The advantage is that fewer parts of the config need updating, i.e. if there are newer library versions
Separation can also make aliases more flexible, used in different contexts
:env/test could include paths and libraries needed to run tests, regardless of the actual test runner.

@practicalli-johnny
Copy link
Contributor Author

From Sean Corfield (summarized)

I have a pretty sophisticated REPL workflow which is "just" a Clojure editor (with Clojure LSP , nREPL and Portal

Additional tools are added via aliases when starting a REPL:

  1. datafication of things
  • Stuart Halloway reflector
  • Jedi Time lib for Java Time types
  1. hotloading libraries (using add-libs) without restarting the REPL.

Also have custom REPL snippets for running tests (and sending the report hash map to Portal).

tap> is my "debugging" tool (rather than a step-debugger). Add tap> calls that stay in the code, even in production without issue. The tap> data goes into Portal to browse and visualize, with datafy/nav making all sorts of interesting things possible, esp. with next.jdbc database results.

@allentiak
Copy link

@seancorfield

@seancorfield
Copy link

An example of how I start my REPL at work:

clojure -J-Dlog4j2.configurationFile=log4j2-sean.properties -M:build:dev:test:everything:runner:add-libs:jedi-time:cider-nrepl:portal:reflect:dev/repl

where the first five aliases are in the project deps.edn and the rest are from my personal dot-clojure file.

As a general principle in nearly all my projects, I separate out :test for test dependencies and paths and :runner which adds the test runner itself and any main/exec arguments needed.

In the above example, :dev and :test are "standard" Polylith aliases (and the project has a :poly alias for running the tool itself) and :everything / :runner are the equivalents for our legacy subprojects in the repo (and, along with :build, provide all that is needed to run tests via Cognitect's test-runner over those legacy subprojects.

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

No branches or pull requests

3 participants