Skip to content

HTML output filename #937

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

Merged
merged 5 commits into from
Jan 13, 2025
Merged

Conversation

tguichaoua
Copy link
Contributor

Add html_output field to config to define the filename of the output HTML file.
When the field is not defined, it uses the same filename as the target HTML file.

@ctron ctron added this pull request to the merge queue Jan 13, 2025
Merged via the queue into trunk-rs:main with commit e4772e4 Jan 13, 2025
60 checks passed
@dVeon-loch
Copy link
Contributor

@ctron @tguichaoua Could you clarify the motivation behind the html_output change?

In many workflows (including mine), trunk serve expects dist/index.html by default. The new behavior breaks this unless html_output is explicitly set. Was this change intended to support multi-page apps, or is there another use case where renaming the output is beneficial?

It might be preferable to change the behaviour of this config to match the previous behaviour (e.g. if this config is not included, then default to renaming to index.html)

If reverting the default behavior isn’t possible, could we add a warning when html_output isn’t set? For example:

Warning: No `html_output` specified. The output file will be named after the source HTML file.
To generate `index.html`, add `html_output = "index.html"` to your `Trunk.toml`.

This would help users quickly identify and fix the issue.

@ctron
Copy link
Collaborator

ctron commented Mar 10, 2025

When the field is not defined, it uses the same filename as the target HTML file.

I think this was not intentional. Maybe needs to be fixed? @tguichaoua

@dVeon-loch
Copy link
Contributor

When the field is not defined, it uses the same filename as the target HTML file.

I think this was not intentional. Maybe needs to be fixed? @tguichaoua

@ctron I have created a PR to fix this behaviour here: #955

Please let me know if it looks good

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

Successfully merging this pull request may close these issues.

3 participants