Adds support for client subdir

[infomiho]

Closes #8

You can now serve the client from a subdirectory. This is useful if you want to serve the client from a subdirectory of your domain, e.g. https://example.com/my-app/.

To do this, you need to add the client.baseDir property to your .wasp file:

app todoApp {
  // ...
  client: {
    baseDir: "/my-app",
  },
}

[infomiho]

Example of usage

[Martinsos]

Reviewed, looks good!

I left some smaller comments, feel free to fix them as you wish and you can merge when you are satisfied.

Some additional questions, but also not critical:

1. How did you choose baseDir for a name? I see Vite uses base, react-router uses basename. I like baseDir the most probably, I think it is the most precise, I am just curious.
2. Idea: what if they need to use the value of "baseDir" in frontend/backend? I can see that being possible? Should we expose it for them, so they can just import it and use it, since Wasp already knows it? Instead of them duplicating it in shared/?

[infomiho]

Note: check out the email sending code that relies on the frontend URL for email verification and password reset. URL in the config probably needs updating. Also the docs need to be updated.

[Martinsos]

Note: check out the email sending code that relies on the frontend URL for email verification and password reset. URL in the config probably needs updating. Also the docs need to be updated.

note: docs should be updated to mention that frontend URL needs to contain that same base dir in it. I wonder if we could even do a check for that in Wasp.

[Martinsos]

Note: check out the email sending code that relies on the frontend URL for email verification and password reset. URL in the config probably needs updating. Also the docs need to be updated.

How are with the email then, all good?

[Martinsos]

Reviewed, looks good!

I left some smaller comments, feel free to fix them as you wish and you can merge when you are satisfied.

Some additional questions, but also not critical:

1. How did you choose baseDir for a name? I see Vite uses base, react-router uses basename. I like baseDir the most probably, I think it is the most precise, I am just curious.
2. Idea: what if they need to use the value of "baseDir" in frontend/backend? I can see that being possible? Should we expose it for them, so they can just import it and use it, since Wasp already knows it? Instead of them duplicating it in shared/?

@infomiho bump on this one, some questions here!

[infomiho]

1. The baseDir name is arbitrary. It felt right given the base and basename nomenclature.
2. I wouldn't add it unless we get explicit requests for it, keeping it simple for now. baseDir is already an edge case, so exposing it an even more of an edge case IMHO
3. Email links now work as expected 👍 I've tested it out locally

[Martinsos]

1. The baseDir name is arbitrary. It felt right given the base and basename nomenclature.
2. I wouldn't add it unless we get explicit requests for it, keeping it simple for now. baseDir is already an edge case, so exposing it an even more of an edge case IMHO
3. Email links now work as expected 👍 I've tested it out locally

Adding baseDir in SDK -> I don't see why that is more of an edge case, it seemed logical to me to give them a way to access that value they defined in .wasp file. Otherwise they will have to duplicate it. They might need it to construct some kind of URL maybe?

[infomiho]

I don't feel we have a strong argument for adding it.

Otherwise they will have to duplicate it. They might need it to construct some kind of URL maybe?

When users start mentioning they need it -> I would then add it. Otherwise, we are adding things we assume could be useful .

[Martinsos]

@infomiho approved! There might be some comments that are still somewhat unresolved, pls make sure those are all in good shape, and then you can merge!

[Martinsos]

Why did this one get indented, if it wasn't indented before? It makes sense to me that it is at the top level, since it says where the config file is, in theory some other part of Generator might want to use that info.

[infomiho]

I saw that it was used only in one place, therefore I moved it inside of the genConfigFile

[Martinsos]

I would say it is not about how it is used currently, it is about how it is intended to be used. We keep all of such paths at top level (if I am correct), because they are often by other modules for imports and similar. You putting into where indicates you mean it to be private/local for this function, so if I want to use it later, I will have to wonder if I can use that one -> it seems like the author didn't intend so.

So I would leave where it was.

[infomiho]

Makes sense 👍 I've reverted the change

[Martinsos]

I don't feel we have a strong argument for adding it.

Otherwise they will have to duplicate it. They might need it to construct some kind of URL maybe?

When users start mentioning they need it -> I would then add it. Otherwise, we are adding things we assume could be useful .

Fair enough -> personally, to me it just makes a lot of sense to have it, and at the end we are always assuming that somebody will use something :D, the question is just how certain are we of it. What is tricky here is that people might not ask for it but just duplicate it. But ok, let's not get stuck on it, we can certainly add it later as you said, hopefully we will be the ones to stumble upon needing it first, if it is indeed useful.