Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Oxidation Compiler

oxc.rs

Post reply on HN
Print view View original

111–120 of 147 posts

Re: The JavaScript Oxidation Compiler

#111

Post by Tadpole9181 »

vladvasiliu wrote: post #80
tomashubelbauer wrote: post #76

Earlier quoted context omitted.

> running oxfmt without any arguments recursively scans directory tree from the current directory for all .js and .ts files and silently reformats them I've got to say this is what I would have expected and wanted to happen. I'd say it is wise to not run tools designed to edit files on files you don't have a backup for (like Git) without doing a dry-run or a small scope experiment first.

While I can get behind things such as "use version control," "use backups", etc. this is definitely not what I'd expect from a program run without arguments, especially when it will go and change stuff.

What? The very first page of documentation tells you this. The help screen clearly shows a `--check` argument. This is a formatter and uses the same arguments as many others - in particular Prettier, the most popular formatter in the ecosystem.

How were you not expecting this? Did you not bother to read anything before installing and running this command on a sensitive codebase?

Re: The JavaScript Oxidation Compiler

#112

Post by phcreery »

xigoi wrote: post #96
rk06 wrote: post #91

Earlier quoted context omitted.

a new user should not expected to know whether to use "--info", "--help", or "-info" or "/info" A power user can just pass the right params. Besides, it is not that hard to support "--yolo" parameter for that use case

Would you enjoy writing `rm --yolo file` instead of `rm file` every time?

In this case, "file" is the arg, not --yolo. `rm` without any args returns `` rm: missing operand Try 'rm --help' for more information. ```

`oxfmt` should have done the same and `oxfmt .`, with the desired dir ".", should have been the required usage.

Re: The JavaScript Oxidation Compiler

#113

Post by ctmnt »

Grom_PE wrote: post #62

I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't. Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them. Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.

I assume you mean what’s more properly called Java style [1], where the first curly brace is on the same line as the function declaration (or class declaration, but if you’re using Allman style you’re probably not using classes; no shade, I’m a JS class hater myself) [2] or control statement [3], the elses (etc) are cuddled, and single statement blocks are enclosed in curly braces. Except I also assume that oxfmt’s default indentation is 2 spaces, following Prettier [4], whereas Java style specified 4.

So maybe we should call it JavaScript style? Modern JS style? Do we have a good name for it?

Also, does anyone know when and why “K&R style” [5] started being used to refer to Java style? Meaning K&R statement block style (“Egyptian braces” [6]) being used for all braces and single statement blocks getting treated the same as multi-statement blocks. Setting aside the eternal indentation question.

1: https://en.wikipedia.org/wiki/Indentation_style#Java

2: https://www.oracle.com/java/technologies/javase/codeconventi...

3: https://www.oracle.com/java/technologies/javase/codeconventi...

4: https://prettier.io/docs/options#tab-width

5: https://ia903407.us.archive.org/35/items/the-ansi-c-programm...

6: https://en.wikipedia.org/wiki/Indentation_style#Egyptian_bra...

Re: The JavaScript Oxidation Compiler

#114

Post by ctmnt »

phplovesong wrote: post #66
Grom_PE wrote: post #62

I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't. Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them. Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.

Git undo?

If only. But `jj undo`?

Re: The JavaScript Oxidation Compiler

#115

Post by WD-42 »

pjmlp wrote: post #48
WD-42 wrote: post #20

Earlier quoted context omitted.

Because Rust makes developers excited in a way that C/C++ just doesn't.

Yeah, it is as if there were never other compiled languages before to rewrite JavaScripting tooling.

Why do people get so mad that other people enjoy a language? If I’m more likely to rewrite some tooling because of the existence of a programming language and it’s more performant, isn’t that good for everyone?

We are programmers we are supposed to like programming. These rust haters are intolerable.

Re: The JavaScript Oxidation Compiler

#116

Post by ljm »

Grom_PE wrote: post #62

I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't. Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them. Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.

Well, one way to boost this command to fame is to open an issue on the repo and crash out.[0]

[0] https://github.com/microsoft/vscode/issues/32405

Re: The JavaScript Oxidation Compiler

#118

Post by vladvasiliu »

Tadpole9181 wrote: post #111
vladvasiliu wrote: post #80

Earlier quoted context omitted.

While I can get behind things such as "use version control," "use backups", etc. this is definitely not what I'd expect from a program run without arguments, especially when it will go and change stuff.

What? The very first page of documentation tells you this. The help screen clearly shows a `--check` argument. This is a formatter and uses the same arguments as many others - in particular Prettier, the most popular formatter in the ecosystem. How were you not expecting this? Did you not bother to read anything before installing and running this command on a sensitive codebase?

I do usually run new tools from somewhere harmless, like ~/tmp, just in case they do something unexpected.

But most formatters I'm used to absolutely don't do this. For example, `rustfmt` will read input from stdin if no argument is given. It can traverse modules in a project, but it won't start modifying everything under your CWD.

Most unix tools will either wait for some stdin or dump some kind of help when no argument is given. Hell, according to this tool's docs, even `prettier` seems to expect an argument:

    > Running oxfmt without arguments formats the current directory (*equivalent to prettier --write .*)
I'm not familiar with prettier, so I may be wrong, but from the above, I understand that prettier doesn't start rewriting files if no argument is given?

Looking up prettier's docs, they have this to say:

    > --write
    This rewrites all processed files in place. *This is comparable to the eslint --fix* workflow.
So eslint also doesn't automatically overwrite everything?

So yeah, I can't say this is expected behaviour, even if it's documented.

Re: The JavaScript Oxidation Compiler

#119

Post by vladvasiliu »

xigoi wrote: post #96
rk06 wrote: post #91

Earlier quoted context omitted.

a new user should not expected to know whether to use "--info", "--help", or "-info" or "/info" A power user can just pass the right params. Besides, it is not that hard to support "--yolo" parameter for that use case

Would you enjoy writing `rm --yolo file` instead of `rm file` every time?

No, but we're not talking about `oxfmt file` here, but `oxfmt` with no argument.

I don't expect `rm` with no argument to trash everything in my CWD. Which it doesn't, see sibling's comment.

Re: The JavaScript Oxidation Compiler

#120

Post by pjmlp »

lioeters wrote: post #67
rk06 wrote: post #64

Earlier quoted context omitted.

> they are betting that JS-the-language is so broken that it cannot even host its own tools. Evan wallace proved it by building esbuild. this is no longer bet. > If their open platform were as powerful as it should be, it would be easy to use it to recreate the kinds of experiences they propose to sell. you would be surprised to know that tech companies may find it cheaper to pay money than developer bandwidth for st…

> esbuild Another example is the TypeScript compiler being rewritten in Go instead of self-hosting. It's an admission that the language is not performant enough, and more, it can never be enough for building its own tooling. It might be that the tooling situation is the problem, not the language itself, though. I do see hopeful signs that JavaScript ecosystem is continuing to evolve, like the recent release of MicroQ…

Which also proves the point that not everything needs to be Rust.
Post reply on HN