Mark recipes as exportable/non-exportable

[sergei-dyshel]

When just file in one package/repo imports file in other package, some recipes are rather not be imported because they are "internal" logic of imported package.

In my use case I have a monorepo of multiple Nodejs packages and use just to overcome a serious limitation of NPM scripts - inability to import scripts/actions from another package. For example, I have Library package which has 2 recipes: build (which builds the library itself) and lint (with [no-cd] attribute) which is meant to be imported by all other packages for linting. So when some other's Justfile imports Librarys Justfile I don't want to build to appear in its list of recipes.

Ideally the interface would be to add [export]/[no-export] per-recipe attributes and global export_all_recipes configuration which makes all Justfile's recipes exportable/non-exportable by default (useful when we want to make all recipes non-exportable and then mark some of them with [export]).

Some notes on why we may want a separate feature for that:

1. One way to prevent importing Justfiles to run specific "parent" task is to shadow it by overriding with empty recipe. But this breaks the level of abstraction by trasferring the burden of "shadowing" to the importing package while shouldn't be aware the non-exportable recipe in the first place. Also shadowed recipe will clutter just --list listing.
2. The above example may not be the best demo for the rationale as the impoting package will most probably override build recipe anyway for its own build logic. But instead of build we could use some more specific task (such as generate-docs).
3. Non-exportable task differs from private task because it appears in just --list and is meant to be run by user.
4. One easy way to achieve this is to have separate Justfile with exported tasks (which in above example would contain lint recipe) and import it in other packages. This solution, however, forces us to split just logic into multiple files which breaks one of the best advantages of just over collection of separate shell scripts - ability to put all the logic into single file.

[casey]

I think this is something that I'd like to solve with modules, not imports. I think the fundamental thing which is needed here is namespacing, and modules already provide namespacing. The issue with modules is that they don't provide a lot of other things, see #2252, which are necessary to replace imports.