When a recipe wraps cli tool and the tool exits with a non-zero code,
just adds its own extra exit error message along with the messages
from the tool. Introduce the `[no-exit-message]` attribute to suppress
this additional message.
Add a new setting "skip-comments", which defaults to true. If unset,
this causes lines internal to a non-shebang recipe beginning with the
character '#' (including '#!' internal to a non-shebang recipe; that is,
any such instances occurring after the first line of a recipe) to be
treated as comments of the justfile itself. They will not be echoed to
stderr when the recipe executes.
This loosens a restriction, and allows falling back to a justfile in a parent justfile
when a search directory is provide, e.g. with `just ..` or `just foo/bar/`. Looking
at it now, I can't really think of why I enforced that restriction in the first place.
Hopefully it's not important 🤷♀️.
This changes the default value of `dotenv-load` from `true` to `false`. This
is a backwards incompatible change, and will require a minor version bump.
Replace all single quotes with `'\''` and prepend and append single
quotes to `s`. This is sufficient to escape special characters for many
shells, including most Bourne shell descendants.
If a `.env` file is found and loaded, but the `dotenv-load` setting hasn't been explicitly
set to true, print a warning to stderr. In approximately six months, `dotenv-load` will
change from defaulting to true to defaulting to false, which will be a potentially breaking
change in behavior for justfiles which elicit this warning.
See this issue for more details:
https://github.com/casey/just/issues/469
This commit adds a `Loader` type, which can be used to load multiple
source strings. This was done to support the work on modules, but
coincidentally enabled consolidating errors, since now `Config::run`
can take a `&Loader`, and in the event of an error, return and `Error`
that borrows from loaded strings. Multiple error types have been
consolidated, and a bunch of ad-hoc error printing was removed.
Subsequents are dependencies which run after a recipe instead of prior.
Subsequents to a recipe only run if the recipe succeeds. Subsequents
will run even if a matching invocation already ran as a prior
dependencies.
- Combine and simplify string and backtick lexing.
- Allow newlines in strings and backticks.
- Add triple-delimited indented strings and backticks. Common indented literal non-blank line leading whitespace is stripped.
- If a literal newline is escaped, it will be suppressed.
- Backticks starting with `#!` are reserved for a future upgrade.
Unify lexing of backticks, cooked strings, and raw strings. Also allow
newlines in backticks and cooked strings, since I can't think of a reason
not to.
It's been around two and a half years, and many versions, since this
warning was first introduced, so it feels reasonable to finally turn it
into a hard error. It will remain a special-cased error for a little
while.
Add a setting that exports all variables by default, regardless of
whether they use the `export` keyword. This includes assignments as well
as parameters.
Just does dependency analysis of variable uses, allowing variables to be
used out of order in assignments, as long as there are no circular
dependencies.
However, use of environment variable is not known to Just, so exported
variables are only exported to child scopes, to avoid ordering dependencies,
since dependency analysis cannot be done.
Add the `--list-heading` option, to override the heading text printed
before a list, defaulting to `Available recipes:\n`, and
`--list-prefix`, to override the indentation before each list item.
Modify the lexer to keep track of opening `({[` and closing `]})` delimiters.
When the lexer would emit an eol or indent outside of a recipe when there
is at least one open delimiter, emit a whitespace token instead.
This allows expressions to be split on multiple lines, like so:
x := if 'a' == 'b' {
'x'
} else {
'y'
}
This does not work inside of recipe body interpolations, although this
restriction might relaxed in the future.
Add conditional expressions of the form:
foo := if lhs == rhs { then } else { otherwise }
`lhs`, `rhs`, `then`, and `otherwise` are all arbitrary expressions, and
can recursively include other conditionals. Conditionals short-circuit,
so the branch not taken isn't evaluated.
It is also possible to test for inequality with `==`.
Remove all manual tracking of which tokens would have been accepted by
the parser in favor of having the parser add tokens that it checks for
to a set of expected tokens, clearing them when it accepts a token, and
using the current contents of the set in error messages.
This is a massive improvement, and will make the parser easier to
modify going forward.
And, this actually solves my sole issue with hand-written parsers.
Thanks to matklad on reddit for suggesting this!
The `--choose` subcommand runs a chooser to select a recipe to run. The
chooser should read lines containing recipe names from standard input,
and write one of those names to standard output.
The chooser defaults to `fzf`, a popular fuzzy finder, but can be
overridden by setting $JUST_CHOOSER or passing `--chooser <CHOOSER>`.
Combine all integration test binaries into a single binary with the root
in `tests/lib.rs`. This also turns of automatic test discovery, so
when adding another set of integration tests, a mod statement will need
to be added to `tests/lib.rs`.
If an environment variable exists with the same key as a variable from a
`.env` file, skip the variable from the `.env` file in favor fo the key
from the environment.
On Windows, skip conversion if a shebang path does not include `/`. In
this case it is not a Unix path, and does not need to be converted to a
Windows path before running.
Make line continuations strip leading spaces on the next line.
This changes what is passed to the shell, so this is a breaking change.
However, I don't think that this will break any recipes.
Add a subcommand that prints out a space-separated list of the names of
top-level variables in the justfile.
The syntax is:
$ just --variables
a b c
This can be used for any purpose, but is mostly intended for completion
scripts, so that they can get the names of variables without using
`--evaluate`.
Additionally:
- Add `bin/generate-completions` script to regenerate checked-in
completions
- Update dependencies
- Regenerate checked-in completions
