-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
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:
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. |
An example of how I start my REPL at work:
where the first five aliases are in the project As a general principle in nearly all my projects, I separate out In the above example, |
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.The text was updated successfully, but these errors were encountered: