I would love to see the
shards functionality merged into the main
When someone gets started with Crystal, they usually write
crystal file.cr and
crystal build file.cr as they work through tutorials. After initializing a project and creating a
shards.yml file though, the pattern changes to
shards build along with running specs via
crystal spec. It feels like the experience would be improved by using
crystal for everything. It would also help Google searches for compiler flags.
Now that Crystal has reached 1.0 and has a regular release cadence, I think any issues we need to address with shards can probably be done via a minor or patch release.
What do you think?
Others can probably expand on this more, but
shards used to a part of
crystal in the form of
crystal deps, but was removed in favor of
In the end it comes down to
crystal being different projects with different goals. Technically speaking
shards build is the only command that directly ties
crystal and it’s just a light wrapper around
crystal build for each of the defined targets. Other than that there is no reason you couldn’t use shards as a dependency manager for other languages, which would be weird if you needed to install a programming language just to install your project’s dependencies. Granted this is unlikely to happen/be used for that, but the point still stands. They are separate projects severing different and separate use cases.
I think it’s fine that they’re separate. Plus you don’t really have to use
shards build, especially if you only have one target.
Yes, dependency resolution is an entirely different task and should be handled independently.
I’d rather remove
shards build than merge shards into the compiler.
Maybe we could consider to merge
shards build into
crystal build. That means just make the compiler read targets from
shard.yml and have them available as aliases for the file paths.
I don’t think this would be a huge improvement though. So it’s probably not worth it.
shards build is easy. And of course, there are actual build systems as alternatives.
It makes sense from a Crystal developer’s standpoint that these two concerns are separated. I would push back though that users of Crystal really appreciate those differences.
In Go, that functionality is tucked under
go mod. So you would
go mod verify or
go mod tidy. That allows the main functionality of
go build to stay unchanged.
Same for Elixir’s
If it were to happen though, it would probably need to be an all or nothing affair so that
crystal build can perform dependency resolution transparently like
shards build does today. It may seem like a trivial little thing, but these things really stand out for newcomers to the language.