Add import aliases and environment variables

[f-elix]

I think these 2 additions would make the starter template even better, as they are features already present in some other frameworks scaffolding (like Vue CLI for example).

1) @ aliases for imports are a convenient way to abstract the src folder path when you want to import something into your components.

Example: import { something } from '@/components/someComponent.svelte'; instead of import { something } from '../../components/someComponent.svelte';

2) Make environment variables available throughout the app (based on the sapper/env plugin https://github.com/JpCapdevila/sapper-environment). Again, this is a nice convenience to have and that is available in other frameworks.

You can now create a .env file to store your environment variables and reference them in your code by using 'process.env.MYVARIABLE'. The way I set it up requires that your env variables start with 'APP', but this is easily customizable.

I found these 2 features lacking when I ported my Sapper app to Routify (and frankly, they are also lacking in Sapper) and I thought it would make for a better developer experience for everyone using this starter template.

[vercel[bot]]

This pull request is being automatically deployed with Vercel (learn more). To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/jakobrosenberg/routify-starter/97rtci1qd ✅ Preview: https://routify-starter-git-fork-f-elix-master.jakobrosenberg.now.sh

[jakobrosenberg]

Hi @f-elix

Thanks for the PR. Routify uses .env, so that should already be present (we do need to document it though). As for rewriting env keys, it subtracts from predictability, adds complexity and would require further documentation.

I personally use alias in the same way as you and have often considered adding it to the starter template. My concern is the introduction of new concepts, lack of predictability and lack of auto completion/type safety in IDEs.

If we introduce alias, we could reduce complexity by using alias as a oneliner:

alias({ entries: [{ find: '@', replacement: './src' }] }),

The official documentation states that alias only resolves .js by default, but from our experience it's resolved all file types we've used, .svelte included.

[f-elix]

Hi,

Thanks for the feedback!

If you think using aliases that way is better I have no problem at all, I'll test it out myself and make the modification if I don't find any issue.

As far as env variables are concerned, do you mean to say that they are automatically available in a Routify app? Because I haven't found this to be the case. I was getting 'process is not defined' errors all over. That is the only I found to make it work. How would you suggest we do that?

[rixo]

While I see the value of the features (alias especially, that I use the same in my own projects), I don't think they should be added to the current starter template. Ideally they'd be options, but the starter format doesn't support options.

The thing is the starter needs to strike a delicate balance between getting you started, exemplifying important techniques like SSR and deployment, all while remaining understandable so that people can learn from it.

We want to empower the user by teaching them how to fish, by the example, rather than dump 1 ton of fish on their front door, if you see what I mean.

Unfortunately, features are additive but complexity is multiplicative, so each added feature / benefit has kind of an exponential cost in terms of complexity...

Given how deep we already are in complexity territory, due to the important core techniques we want to demonstrate with Routify, I think we should be extremely cautious with what else we're adding to the official starter. Comfort or luxury features don't make the cut for me.

We also need the main starter to avoid being too opinionated. The goal is not for people to have to remove half of it because it doesn't suit their own taste...

That being said, I do think that, at this point, multiple starter templates would be ideal -- unfortunately the current team doesn't have the resources to maintain more than one. But simple ones for simple projects. Complete but lean ones for beginners. Feature rich ones, for advanced developers who already understand it all and want to skip the legwork to get started.

@f-elix Your proposal falls in the last category for me. It'd be great if you want to make a more opinionated community starter.

@jakobrosenberg Might be good to list community starters as possible alternatives somewhere prominent enough in the official docs? Maybe adopt some as official variants, if there are people interested in maintaining them?

[f-elix]

@rixo Thanks for the input, I do understand better now what the goal of this starter is.

I'll see what I can do about another template. I did find a nice way (at least I think, feedback would be welcome) to easily integrate a service worker in the template, so maybe I'll explore that a bit more.

The only thing bugging me here is the environment variables. I don't really consider them to be a luxury. I may have misunderstood though. @jakobrosenberg said Routify was already using dotenv, but without the code I added in the config, none of my .env variables are accessible in my app, I just get undefined. Is there something I'm missing? Maybe there is a more obvious way that I haven't seen.

In any case, feel free to close this PR, and thank you all for your great work! I think Routify will be a very good thing for Svelte.