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

The Rome Toolchain: A linter, compiler, bundler, and more

github.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: The Rome Toolchain: A linter, compiler, bundler, and more

#11

Post by pseudoramble »

acemarke wrote: post #7
pseudoramble wrote: post #5

When 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…

That's a good point, and one that I've forgotten since I've been out of the JS world for a while now! Often you're trying to run the code in different environments depending on the context, which does require a lot of extra build tool support. Consolidating that is a reasonable goal, I'd say.

It will be neat to see where they draw the line. For example, will Rome include an assertion library? What about mock and fake support? That feels a bit far from what Rome is trying to do, but if they've implemented a test runner, maybe defaults provided would be good for the DX?

Re: The Rome Toolchain: A linter, compiler, bundler, and more

#12

Post by acemarke »

pseudoramble wrote: post #11
acemarke wrote: post #7

Earlier 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…

That's a good point, and one that I've forgotten since I've been out of the JS world for a while now! Often you're trying to run the code in different environments depending on the context, which does require a lot of extra build tool support. Consolidating that is a reasonable goal, I'd say. It will be neat to see where they draw the line. For example, will Rome include an assertion library? What about mock and fake…

_That_ is an excellent question, and I honestly have no idea what their plans are in that respect :) I've seen a number of Sebastian's tweets over the last couple years as he was working on Rome, and have glanced at the repo README, but haven't poked at the actual work they're doing.

Part of the sales pitch for Jest is that it includes a set of APIs for mocking and assertions built in. Wouldn't surprise me if Rome did the same, but curious how they'd design things.

Re: The Rome Toolchain: A linter, compiler, bundler, and more

#15

Post by ratww »

pseudoramble wrote: post #11
acemarke wrote: post #7

Earlier 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…

That's a good point, and one that I've forgotten since I've been out of the JS world for a while now! Often you're trying to run the code in different environments depending on the context, which does require a lot of extra build tool support. Consolidating that is a reasonable goal, I'd say. It will be neat to see where they draw the line. For example, will Rome include an assertion library? What about mock and fake…

It will probably include module-mocking in it (aka jest.mock), since it happens during "bundling"/compilation, but the assertion and function mocking can certainly be handled by a third-party library.

Re: The Rome Toolchain: A linter, compiler, bundler, and more

#18

Post by ratww »

Touche wrote: post #8
acemarke wrote: post #7

Earlier 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 really: dynamic languages (Python, Ruby, PHP) also have special cli testing tools just like JS, and that's where JS got inspiration from. What makes JS different is that it started having a compilation phase along the way, so both approaches hat to be combined.

Re: The Rome Toolchain: A linter, compiler, bundler, and more

#19

Post by cjamesd »

Kind of goes without saying, but the flip side of having all of these tools under a single opinionated umbrella is that if any piece of it sucks, people are going to drop the whole toolchain. Hence this is a high risk project, especially because everything is being built from scratch.
Post reply on HN