feat: Add allow_unknown_extensions macro param

[angrynode]

Not sure if that's how you want to do things but i find it annoying that my program doesn't compile when there is an unknown extension.

In my daily usage it's not been a great problem but lately i've been working with a person who uses MacOS so there's .DS_STORE files everywhere preventing compilation.

in this PR i add an infallible feature flag which uses mimetype binary/octet-stream when it cannot be guessed, instead of crashing compilation.

[paolobarbolini]

Hey @angrynode, thanks for the PR! I don't mind falling back to a default content type when the extension is unknown.

The correct value though is application/octet-stream, not binary/octet-stream. I'm not sure if we want this feature to be controlled by a cargo-native feature, which both in a good and in a bad way is global, or if we want this would be an additional flag that the user is able to control via the macro.

[angrynode]

The correct value though is application/octet-stream, not binary/octet-stream

Good catch, thanks!

if we want this would be an additional flag that the user is able to control via the macro

I'm not sure i know how to implement this, as i'm not familiar with macros. Maybe i'll find time for this in the next weeks, but if you feel like this feature is useful, don't wait for me :)

[ThinkerDreamer]

Hi @angrynode! Thank you for your PR! I agree with @paolobarbolini that it might be better to make this a flag inside the existing macros rather than a cargo feature. This was my first proc macro too, and it's not as hard as I thought 😄 So if you want to give it a try, it could be a nice way to learn! You can look at what I did with the other flags ("compress", "cache_bust", "ignore_paths", "strip_html_ext", etc.) to see how to handle adding a new one. I think your infallible_content_type function looks good, just remember to change binary/octet-stream to application/octet-stream like @paolobarbolini mentioned.

[angrynode]

OK i've added the macro param. I'm not sure i'm doing everything OK, it's confusing to me what should be expecting a LitBool or a bool.

Also i don't think it's specific to this PR, but i find the error confusing: error: Missing file extension

We should probably store the entire filename in the error so it's easier to find the source of the problem, don't you think? If you agree, should i add a commit as part of this PR or open a new PR about this?

[ThinkerDreamer]

@angrynode I gave it a quick look and everything seems in place. Could you write a couple tests to check that the new parameter works as expected? You can create a new empty (or small) file with a weird extension (or even .DS_STORE, your exact use-case) as test fixtures.

[ThinkerDreamer]

As for the error: Missing file extension part, yeah, that's a good point. I wonder if there's an easy way to get the filename into that error. It should probably be part of a new issue/PR though, yeah.

Edit: Yeah, I just checked and it shouldn't be too difficult. We can just put the whole path as a string into the error instead of None. We should probably have an enum for either InvalidExtension(OsStr) or MissingExtensionInPath(String) for that, rather than the Option<extension here> we use now

[angrynode]

I added a successful test, and a failing test. The failing test had to go in a docstring to use the compile_fail attribute.

I also updated the README docs about the new attribute.

[ThinkerDreamer]

Very nice! I left a few small change requests, mostly typographical errors.

[ThinkerDreamer]

Oh, one more thing: could you also add your line about allow_unknown_extensions to the #### Optional parameters section of ### Embedding a directory of static assets in the README.md as well? Currently it's only under the ### Embedding a single static asset file section.

[angrynode]

Thanks for the review. I edited accordingly.

[ThinkerDreamer]

Great! Looks good to me! Thanks again!