replace prettier with dprint for "deno fmt"

[ry]

https://dprint.dev/
https://github.com/dsherret/dprint/tree/master/packages/rust-dprint-plugin-typescript
dprint is a TS formatter written in Rust by David Sherret @dsherret

[nayeemrmn]

Based on this, #3427 (comment) and #3806, is the goal to not have any std dependent subcommands at all? That would solve a lot of problems. No one's mentioned moving over the test runner which seems like one of the easier ones to move.

[bartlomieju]

Based on this, #3427 (comment) and #3806, is the goal to not have any std dependent subcommands at all? That would solve a lot of problems. No one's mentioned moving over the test runner which seems like one of the easier ones to move.

That's correct. Test runner is more tricky though. First it shares some functionality with formatter (walking dir tree and finding matching files), so it should wait until we land it. Second, test runner still needs to run tests - this is done by runTests method from std/testing/mod.ts. It definitely needs more thought.

[nayeemrmn]

test runner still needs to run tests - this is done by runTests method from std/testing/mod.ts

Moving test() and runTests() to ops shouldn't be very difficult -- testing/mod.ts is kind of messy (e.g. it shouldn't have any original exports) so it's hard to tell exactly, but they're quite isolated. The only non-trivial dependency is the glob expander which is easy to replace in rustland and an inevitability in the CLI. No reason to be blocked by the formatter.

Rather, a blocking point of thought is how to enhance the API in light of first-class support. For example, I don't think we need to expose a Deno.runTests() op.

[bartlomieju]

The only non-trivial dependency is the glob expander which is easy to replace in rustland and an inevitability in the CLI. No reason to be blocked by the formatter.

That's correct;

First it shares some functionality with formatter (walking dir tree and finding matching files), so it should wait until we land it.

I will open up formatter PR shortly, @nayeemrmn I would very much welcome help on glob expander and include/exclude filter.

[kitsonk]

Also, I guess this is a breaking change that removes #3033, where some people will have expectations around those configs.

[nayeemrmn]

Are we going to change the default rules to be more like prettier's? The current ones are yucky.

[dsherret]

@nayeemrmn see #3824. Let me know about any other changes that should be made or configuration added.

[dev-nicolaos]

Just out of curiosity, what was the motivation for this? Is it that dprint is written in rust and that improves performance, or makes maintenance easier?

Also, the dprint website says it currently only supports ts and jsonc. Does this mean no support for .js files? That seems like it'd be a huge step backwards for deno fmt.

[dsherret]

@dev-nicolaos the one used in deno supports .js, .jsx, .ts, and .tsx files and it's much faster than prettier. I would say this is a temporary step backwards, but once we sort out the bugs and implement a few additional features then we will be many steps ahead.

Few points:

• There's no configuration file at the moment, but once it's added there will be a lot more configuration options than prettier with more to come. Follow fmt: add config flag #3827 for updates on that.
• I'm currently working on markdown support and that will be available within a few weeks. Follow updates for that at Add markdown formatting in rust dprint/dprint#60
• If you run into any issues using it then please open up an issue at https://github.com/dsherret/dprint/issues and I will look into it. I bet there are a large number of edge cases I haven't considered.

[kitsonk]

Also, in theory, dprint uses a crate which generates AST for TypeScript. While it is a long long road, we might parse TS/JS in Rust and hand the AST over to the TypeScript compiler for type checking and emitting.

[bartlomieju]

Also, in theory, dprint uses a crate which generates AST for TypeScript. While it is a long long road, we might parse TS/JS in Rust and hand the AST over to the TypeScript compiler for type checking and emitting.

@kitsonk given we have parsed nad JSON serialized AST, in the present, is there actually a way to load it into compiler just for type check and emit? What changes would our compiler host require?

[kitsonk]

is there actually a way to load it into compiler just for type check and emit?

No. See microsoft/TypeScript#33502. I am not sure how much the core team are going to be interested in it, so it might be something that we need to contribute. I also suspect there is a gap between what swc currently produces and what we would need to hydrate an AST for the compiler. It is a long road, but we can chip away at it.