The Rome Toolchain: A linter, compiler, bundler, and more
1–10 of 34 posts
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#2The twitter discussion leading for the new domain and name of the project https://twitter.com/sebmck/status/1319870764435316736
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#3I was confused for a moment, because this has the same name as a companion tool for Carthage. https://github.com/tmspzz/Rome
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#4I started using webpack in 2015. It's still the tool I reach for when doing JS. It's not going anywhere.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#5When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying.
One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fill the gaps for testing, including JS. Is there a big advantage to pulling it into Rome?
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#6When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fi…
I guess the argument is that testing is very often another piece of the "developer experience" of a project, akin to linting or compilation. It makes some amount of sense to me, although I see where you're coming from.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#7When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fi…
If you look at configuring a tool like Jest, there's a ton of "build tool" overlap, typically involving configuring Babel/TypeScript, parsing, path aliases, and so on. In particular, you usually have duplicate configuration for Jest and Webpack for all those things, but with completely different config file formats. Test runners also need to be able to iterate over files, run checks, and print diagnostics.
Those all sound like things that Rome has the ability to do already, _and_ it's another tool that Rome could eliminate from a typical install.
I'm not planning to switch to Rome any time soon, but I definitely understand the mindset involved in that approach.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#8When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fi…
If you look at configuring a tool like Jest, there's a ton of "build tool" overlap, typically involving configuring Babel/TypeScript, parsing, path aliases, and so on. In particular, you usually have duplicate configuration for Jest and Webpack for all those things, but with completely different config file formats. Test runners also need to be able to iterate over files, run checks, and print diagnostics. Those all…
This is a weird peculiarity of the JS ecosystem. The rest of programming ecosystems do not have dozens of tools all doing a build for you. When you run tests in C you do not use a special cli testing tool that also compiles your project... You just run cc on your test files and run it like everything else. Why JS prefers hiding the build I'll never understand.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#9Earlier quoted context omitted.
If you look at configuring a tool like Jest, there's a ton of "build tool" overlap, typically involving configuring Babel/TypeScript, parsing, path aliases, and so on. In particular, you usually have duplicate configuration for Jest and Webpack for all those things, but with completely different config file formats. Test runners also need to be able to iterate over files, run checks, and print diagnostics. Those all…
This is a weird peculiarity of the JS ecosystem. The rest of programming ecosystems do not have dozens of tools all doing a build for you. When you run tests in C you do not use a special cli testing tool that also compiles your project... You just run cc on your test files and run it like everything else. Why JS prefers hiding the build I'll never understand.
Not sure I agree with that statement. For example, I know that nUnit and jUnit are test runners for the .NET and Java ecosystems, and both of those are also runnable via the CLI.
As for the JS ecosystem, it's definitely developed differently than other languages, because it deals with a very different set of constraints. See this article for background explanation (which also links to further reading)
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#10When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fi…
I guess the argument is that testing is very often another piece of the "developer experience" of a project, akin to linting or compilation. It makes some amount of sense to me, although I see where you're coming from.
Right. I'm genuinely not trying to make a judgement on the choice - it's just not the choice I'm used to seeing, including in JS environments. So it seems like there must be some reasoning behind it.
I suppose that's true! Practically speaking, it would be nice to have one testing framework to learn and use over-and-over again, but that's also kinda counter to what I'm used to in the JS world.