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.
