Feature request: Do not add a slash for `--public-url .`

[neocturne]

This is the same issue as #165, which was closed as the original reporter did not want to pursue it any further.

It would be great if there was a way to make the generated page path-independent by not using any absolute paths (I'd even argue that this should be the default). As far as I can tell, this is currently not possible; the commands suggested in #165 do not work:

• trunk build --public-url . generates the following:

<script type="module">import init from '/./index-aff7550d9c9c0030.js';init('/./index-aff7550d9c9c0030_bg.wasm');</script>

• trunk build --public-url '' generates the following:

<script type="module">import init from '//index-aff7550d9c9c0030.js';init('//index-aff7550d9c9c0030_bg.wasm');</script>

I can make this work by editing the generated file manually to the following:

<script type="module">import init from './index-aff7550d9c9c0030.js';init('./index-aff7550d9c9c0030_bg.wasm');</script>

[max-sixty]

If anyone has a workaround for this, that would be great — I'm planning on using sed or similar... Thanks in advance.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[colons]

i would very much like this to not be closed. as it is, it seems impossible to cleanly serve multiple trunk apps from their own folders on a simple file-based web server, or deploy to a shared domain (unless you're willing to bake their paths into the build, which makes things much less flexible)

[j-brn]

+1 this makes it really annoying to deploy trunks app to github pages

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[colons]

please do not close this issue.

[ctron]

As PR https://github.com/trunk-rs/trunk/pull/616 was merged, I assume this should be closed with the next release of trunk.

[ctron]

I think that's released as part of trunk 0.18.0. If not: sorry, please re-open.

[colons]

i'm a bit confused about the specifics of how this has been addressed. why are you checking for './' specifically, and not '.' or empty strings? those are the two things i thought to try, much like the author of this issue, and neither of those are respected in this case. i guess you can't stop adding a leading / in most cases for compatibility reasons, but it seems actively hostile to override the user's stated intention to set the base url as simply '.'

[ctron]

I am sure there's room for improvement. If you have a good way do deal with all of this, I would really appreciate if you could create a tracking issue with a proposal.

[colons]

i could do that if you really prefer, but it would just be a duplicate of this one. my request here is for trunk to not add a leading slash when . or the empty string are handed in as --public-url. this is precisely the proposal made in this issue's title and description, and #616 does not implement it

[colons]

(i also feel like i'm missing information here. i don't understand why trunk adds / at all, and i feel like . makes the most sense as a default public url. if i want a leading /, i'd type that. but changing this behaviour would be a pretty severe backwards incompatibility, and i think the changes proposed here are the best compromise for now; they are the things that people will try when they see that a / is being added)

[ctron]

Right, I fully agree that it's a bit messy right now. But maybe working towards a breaking change for 0.19 makes sense? But for that it also might make sense to create a tracking issue, not carrying all the history of this issue.

[colons]

okay, thank you; if breaking changes are on the table, that changes things. i've opened #668