Hey Devon! We're using this module for val.town and running into a bug that I had hoped was just because the dprint version was a little old, so did a quick upgrade of the deps here!
The bug still remains, which is wacky - a line of exported code with a single newline character gets deleted:
> require('./').format('index.ts', 'export const x = 10;\n')
''
But that's upstream! In the meantime, this brings the dprint version from June 28, 2022 to about June 9, 2023. Doesn't go all the way to 0.63.2 because the typescript plugin is pinned to dprint-core ^0.62.0 instead of ^0.63.0.
EDIT: figured it out 🤦 dprint-plugin-typescript returns None when the formatted code matches the input! So it's a simple trick dprint-node that instead of .unwrap_or(String::new()), we should do .unwrap_or(code), which returns the existing code! This is assuming that we want format(code) => code as the signature - imho returning an empty string for "doesn't need formatting" is a confusing behavior, and if there is a "doesn't need formatting" return value it should be more obvious than an empty string. I think returning the existing code is what I'd expect, and which is what this PR implements.
Note: this has autoformatting from rust-analyzer. Happy to tweak that to fit the project style - is this autoformatted with a different formatter which I can configure?
devongovett
commented
1 year ago
Hey Devon! We're using this module for val.town and running into a bug that I had hoped was just because the dprint version was a little old, so did a quick upgrade of the deps here!
The bug still remains, which is wacky - a line of exported code with a single newline character gets deleted:But that's upstream!In the meantime, this brings the dprint version from June 28, 2022 to about June 9, 2023. Doesn't go all the way to 0.63.2 because the typescript plugin is pinned to dprint-core^0.62.0instead of^0.63.0.EDIT: figured it out 🤦 dprint-plugin-typescript returns
Nonewhen the formatted code matches the input! So it's a simple trick dprint-node that instead of.unwrap_or(String::new()), we should do.unwrap_or(code), which returns the existing code! This is assuming that we wantformat(code) => codeas the signature - imho returning an empty string for "doesn't need formatting" is a confusing behavior, and if there is a "doesn't need formatting" return value it should be more obvious than an empty string. I think returning the existing code is what I'd expect, and which is what this PR implements.Note: this has autoformatting from rust-analyzer. Happy to tweak that to fit the project style - is this autoformatted with a different formatter which I can configure?