Alias for require "../../../../../../coolfile"?

Community
1

Is there syntax for something like shortening

require "../../../../../../coolfile"?

to

require "~/foo/coolfile"?

?

~ (or another symbol) would be shorthand for project root or ./src/

this is common in javascript.

2

I suggested this and was shot down. I still don’t quite understand why because I think it’s a clear win. I’d love to see it in crystal!

3

Could you elaborate on use cases for this?
The general idea is that required code is either from a library (i.e. shard) in lib folder or relative to the current file. What do you need relative to the project root for?

4

Its useful because require "../../../../../../coolfile" is bad for maintenance in large projects.

5

Would that be relative to the project root, if you are in a project, and relative to the current shard, if you are in a shard? I’m having a bit of trouble understanding how to distinguish both cases when you have that in a project with shards. That is, a shard uses that path but you are in a project that uses that shard.

I’m almost sure it’s doable by checking something something relative to the crystal path, but I’d like to see a pseudo algorithm for this.

6

and if you just have a crystal file in a directory, is it relative to the file?
Or relative to the place you started the compiler from?

7

Maybe what I would do is put alias definitions in a file like shard.yml or alias.yml. So users could define aliases that only apply in their project or in their shard. Somebody might like ~ for their root, somebody else might like @server, @client, @tests.

8

But why do you have such a long path in the first place? What’s the use case?

9

Custom aliases in shard.yml are most certainly not going to happen. I can imagine there might be uses cases. But there are probably only going to be a couple of really useful path references and then they should be hard coded, so they have the same meaning everywhere.

10

Some workarounds:

  1. Any linked directory in ./lib will be searchable as a shard. The require logic is flexible enough probably to find something that will suit your needs.

  2. Any other directory can take part in this lookup. Change your CRYSTAL_PATH env variable and include your wanted sources. Use $ crystal env to check the current values.

  3. Maybe a way to have that option right now in your project is to have a macro that will search for the first shard.yml file and use that as information.

Yet I find appealing the idea of ~ meaning root of the context shard. But I have not needed it so far. I usually don’t deal with such nested files.

11

What if it were something like shards setting up a PROJECT_ROOT env var that matches the location of the shards.yml. Then in the project the author could do something like `require “#{ENV[“PROJECT_ROOT”]}/src/coolfile”.

Not sure how that would work for shards themselves that are in the lib dir. Maybe a separate SHARDS_ROOT or something.

12

They can always be required as shardname.