Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Astro.url shows .html file extension when it shouldn't #10996

Open
1 task
patrickreiner opened this issue May 9, 2024 · 9 comments
Open
1 task

Astro.url shows .html file extension when it shouldn't #10996

patrickreiner opened this issue May 9, 2024 · 9 comments
Labels
needs discussion Issue needs to be discussed

Comments

@patrickreiner
Copy link

Astro Info

Astro                    v4.8.2
Node                     v20.12.1
System                   macOS (arm64)
Package Manager          npm
Output                   hybrid
Adapter                  @astrojs/vercel/serverless
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

In my astro.config.mjs I set:

export default defineConfig({
...
trailingSlash: 'never',
})

and in my vercel.json I set:

{
"cleanUrls": true,
...
"trailingSlash": false
}

The site works as expected, however, calling Astro.url in any .astro file returns the url with the file extension. For example, on the page:

https://astro-url-file-extension.patrickreiner.com/about

calling Astro.url returns

https://astro-url-file-extension.patrickreiner.com/about.html

This is counterproductive because in order to check, for example, what the current url is, I need to write:

Astro.url.toString().replace('.html', '')

What's the expected result?

Astro.url should understand from the configuration that it should never include the file extension in the url

Link to Minimal Reproducible Example

https://github.com/patrickreiner/astro-url-file-extension

Participation

  • I am willing to submit a pull request for this issue.
@github-actions github-actions bot added the needs triage Issue needs to be triaged label May 9, 2024
@ArmandPhilippot
Copy link
Contributor

Based on your example, it seems to be the expected behavior. It is the build.format option that affects Astro.url. See: Effect on Astro.url:

* file - The Astro.url.pathname will include .html; ie /foo.html

Instead, you could try:

{
  build: {
    format: 'directory'
  }
}

But I don't know what you are trying to achieve so maybe it is not suitable for you...

@patrickreiner
Copy link
Author

patrickreiner commented May 9, 2024

Hi @ArmandPhilippot,

I appreciate your comment. I can definitely work around the issue, I just find it counterintuitive to set "cleanUrls": true in my config, and when browsing the site never having a .html extension anywhere, and at the same time having Astro.url return the url with the file extension.

Additionally, I find this problematic because in development this wasn't obvious, so when I initially deployed to production my navigation bar couldn't properly select the current page because I was comparing, for example, '/about' with Astro.url.pathname to see if they match. They matched in development, but not in production.

I'm really just raising this issue because I find it quite counterintuitive as a developer, and I also don't see how this behavior is useful. I can definitely work around it, and it's fine, I just wanted to raise the issue.

Thank you.

@patrickreiner
Copy link
Author

patrickreiner commented May 9, 2024

Or, perhaps, it might be a good idea to also add a 'cleanUrls' option to astro.config.mjs? That way the behavior would be more standardized.

@ematipico
Copy link
Member

ematipico commented May 10, 2024

I just find it counterintuitive to set "cleanUrls": true in my config,

Where is this option coming from? Astro doesn't have this option.

Additionally, I find this problematic because in development this wasn't obvious

We document it, as part of the output format. Is there anything else we should do to make it more explicit?

Astro.url comes from Astro.request.url, and the request is actually sent as output of your build format. Other than documenting it, I'm not sure there's much we can do.

@patrickreiner
Copy link
Author

Hi @ematipico, the "cleanUrls" is an option that can be set in vercel.json, which isn't technically astro, but since Vercel is a deploy partner I think it would be nice to mirror that option so the behavior can be consistent.

I do just want to say that I absolutely love Astro, it's been so fun to work with, which is why I'm taking the time to raise this issue here. I respect and honor your perspective on this and if you don't feel anything can be done, or needs to be done here, we can close this issue. I can continue just writing Astro.url.toString().replace('.html', '') in my code as needed, I just wish there was a way to have Astro.url mirror the actual url used in production.

@matthewp
Copy link
Contributor

Hey @patrickreiner, thanks for bringing up the discussion. My instinct is that we don't want to make a change here because the reason for using format: 'directory' is because you either:

  • Have existing URLs that you want to preserve.
  • You are using a host that doesn't support the index.html pattern (AWS S3 for example).

Since you are using Vercel, why are you using format: 'directory' in the first place?

@matthewp matthewp added needs discussion Issue needs to be discussed and removed needs triage Issue needs to be triaged labels May 13, 2024
@patrickreiner
Copy link
Author

Hi @matthewp,

I'm actually using build: { format: 'file' } and then just stripping off the .html with something like Astro.url.toString().replace('.html', '').

Please correct me if I'm wrong, but my understanding is that even if I used build: { format: 'directory' } I'd still have to do a string replace, removing the trailing from Astro.url. I really don't mind which I use, either 'file' or 'directory', but both would require me to manually "massage" the Astro.url string.

Through this discussion I'm realizing that what I'm actually asking for is actually a new feature request. I think it would be great if Astro config could have an option similar to the vercel config where we set "cleanUrls": true, and then Astro.url wouldn't include the .html.

Or perhaps some other method, like Astro.cleanUrl that would return it (that way Astro.url can remain unchanged).

It's a relatively small thing, but I do think this would be a great feature for sites that don't use trailing slashes and don't show .html filenames.

I appreciate your consideration.

@matthewp
Copy link
Contributor

@patrickreiner what do you want your URLs to look like? It sounds like you don't want to use format: 'file' at all. If you don't want the trailing slash you should use trailingSlash: 'never'. See https://docs.astro.build/en/reference/configuration-reference/#trailingslash

@patrickreiner
Copy link
Author

Hi @matthewp, I agree with you, I tried switching over to format: 'directory' and realized that actually works much better for my use case.

What tripped me up initially when I tried this a few weeks ago, was that Astro.url, even with trailingSlash: 'never', still adds a trailing slash to the home page url, and that was the only url I tried initially. I didn't realize that every other url on the site wouldn't have that trailing slash added to it.

The other thing that tripped me up is that in the astro documentation it says:

To prevent inconsistencies with trailing slash behaviour in dev, you can restrict the trailingSlash option to 'always' or 'never' depending on your build format:

directory - Set trailingSlash: 'always'
file - Set trailingSlash: 'never'

That also confused me, because I thought I'd have to set trailingSlash to 'always' and I didn't want to do that.

I really appreciate you all contributing to this discussion, it helped me better understand the differences between format: 'file' and format: 'directory'.

How come Astro.url adds a trailing slash only to the home page (root url) even when trailingSlash is set to false, but none of the other urls? Is that intentional?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Issue needs to be discussed
Projects
None yet
Development

No branches or pull requests

4 participants