development
project:./deps.edn
.development
directory.deployable
project:projects
directory where each project has its own directory.deps.edn
config file that specifies which libraries, component and bases that are included.resources
directory.test
directory, e.g. projects/my-project/test
.src
directory since all production code should normally only live in components and bases.:project
key in ./workspace.edn
configures which alias each project has and whether any tests should be excluded.workspace.edn
, the project heading will show up as ?
when we execute the info
command, so let's add it:user
and cli
to projects/command-line/deps.edn
:poly/
followed by the brick name, e.g. poly/user
or poly/cli
as in this case. The reason all paths begin with "../../" is that components
and bases
live two levels up compared to projects/command-line
and not at the root as with the development
project.test
command will figure out what tests need to be executed. If you have reasons to run the tests for each project separately using tools.deps, then you also have to specify the test paths.Note: All the projectdeps.edn
config files under theprojects
directory specifies what bricks to include by giving a list of:local/root
mappings. The polytest
command uses this information to figure out what bricks and library dependencies that should be included when executing the tests, by looking into each brick'sdeps.edn
file. tools.deps does not "inherit" test dependencies from:local/root
mappings, which is the reason we have to add our dependencis as separate paths in/deps.edn
to allow IDE's and other tooling to work properly.
./deps.edn
> :aliases
> :dev
> :extra-paths
projects/PROJECT-DIR
> deps.edn
> :deps