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

format behavior change #50

Closed
a-frantz opened this issue Jan 8, 2025 · 5 comments
Closed

format behavior change #50

a-frantz opened this issue Jan 8, 2025 · 5 comments
Assignees

Comments

@a-frantz
Copy link
Member

a-frantz commented Jan 8, 2025

The current default behavior of sprocket format is to accept a single document, format it, and print the result to STDOUT. That isn't very useful in many contexts.

We should drop this behavior, and require either the --overwrite flag or the (new in #49 ) --check flag.

@Scott8440
Copy link
Contributor

I'll also work on this one

@a-frantz
Copy link
Member Author

a-frantz commented Jan 9, 2025

Great! Before you get started, I just want to ping the rest of the team and ensure what this issue proposes (originally an idea from @adthrasher ) is exactly what we want. @claymcleod and @peterhuene haven't weighed in yet.

@claymcleod
Copy link
Member

I think this is fine from a next step perspective. It's also relatively straightforward. I do think we should consider doing what cargo fmt does, which is make sure things are committed to source control before formatting. That being said, that's a bit more of an involved change, so I think we should go ahead with this to slightly improve things in the meantime.

@a-frantz
Copy link
Member Author

a-frantz commented Jan 9, 2025

I think this is fine from a next step perspective. It's also relatively straightforward. I do think we should consider doing what cargo fmt does, which is make sure things are committed to source control before formatting. That being said, that's a bit more of an involved change, so I think we should go ahead with this to slightly improve things in the meantime.

I agree. What's proposed in this issue is kind of a stop-gap to improve the UX immediately. It shouldn't be the behavior long-term, but it's good enough for now.

@Scott8440 you have the go-ahead to start work on this! Really appreciate your contributions :)

@claymcleod
Copy link
Member

Closed in #51.

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

No branches or pull requests

3 participants