Skip to content

feat: Make fluent_syntax::parser::core::Parser pub - #394

Open
danielrainer wants to merge 1 commit into
projectfluent:mainfrom
danielrainer:make_parser_pub
Open

danielrainer wants to merge 1 commit into
projectfluent:mainfrom
danielrainer:make_parser_pub

Conversation

@danielrainer

Copy link
Copy Markdown

This allows creating a simple FTL formatter by parsing and then immediately serializing the parsing result again.

@danielrainer danielrainer changed the title feat: make fluent_syntax::parser::core::Parser pub feat: Make fluent_syntax::parser::core::Parser pub Nov 10, 2025
This allows creating a simple FTL formatter by parsing and then
immediately serializing the parsing result again.
@danielrainer

Copy link
Copy Markdown
Author

I just played around with this some more and it turns out that with Parser accessible, quite a lot becomes possible. For example, I just built a POC tool for renaming IDs and variables on top of fluent-syntax.

danielrainer pushed a commit to danielrainer/fluent-ftl-tools that referenced this pull request Feb 28, 2026
This fork differs from mainline `fluent-rs` by a single line, which
makes `Parser` from the `fluent-syntax` crate public. We need this
because our code depends on the parser for much of its functionality.

There is an open PR for this, but so far it hasn't been addressed:
projectfluent/fluent-rs#394
@alerque
alerque self-requested a review September 25, 2026 22:39
@alerque

alerque commented Sep 25, 2026 •

Copy link
Copy Markdown
Collaborator

@danielrainer Is this in use via your fork for Fish shell now? Or via patches in Debian? At first glance it seems pretty reasonable, but there are a couple of questions about the things this drags with it and whether that's API surface we really want to support as part of the versioning contract.

It would help if you could comment on what method(s) or other access is necessary to be public to be useful. A number of things inside Parser are currently marked pub fn which currently implies pub(crate). Would it be possible to change any/all of the methods to pub(crate) or pub(super) so that they were not exposed? Then we could look more carefully at just the API surface you actually want to use and whether it makes sense to support it being public.

And sorry for the long delay in review.

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.

2 participants