The amount of files in a Rails project root folder are getting out of hand, and the JavaScript ecosystem is certainly one cause to that. Let’s compare a project of mine from 2013 with one of today:
The way I see it, files in the Rails root folder should be scarce because they mean overhead for newcomers (and me as well). Folders are OK for me I guess. JavaScript doesn’t feel like a first class citizen in our Rails applications but more like a compulsive hoarder.
Interesting! I think I agree with you, but I’m having a bit of a hard time thinking of a productive resolution here. I see the root cause as Rails packaging more tools, and I don’t think it’s a bad thing for tools to default to looking in the project root for config.
I think there might be potential in figuring out how to move most of this stuff into config, but my concern there is that existing tutorials will point people to creating things in the root directory. So when that doesn’t work we’re creating a confusing newbie experience of another sort.
Maybe I’m not being creative enough with my solutions, though.
For some history here, at one point we tried adding binstubs for Yarn et al. and moving their config into the config/ directory. But this setup was fiddly and brittle—for example, if you didn’t have ./bin in your $PATH, you’d have to remember to call bin/yarn instead of just yarn, or you’d get errors. So we acquiesced to third-party defaults.
The other pain point was that upstream Yarn, Babel, etc. documentation tend to assume that their config is in the project root, which confused a lot of people.
The beauty of Rails has always been convention over configuration. If I wanted to accept the default choices of the Rails maintainers, ideally there would be no extra files in the root directory.
As it stands, I have to figure out which (non-Ruby) tools the files are for, what those tools do, and whether I should adjust the configuration. But that’s only the start of the problem, I also have to familiarise myself with them across their entire lifecycle. Is this .json config file now supposed to be .js? Is it superseded by another tool entirely? Does the bootstrapped configuration need to be updated to stay current with new versions of Rails? What needs to change to go from Sprockets to Webpacker? What about npm to yarn? Yarn 1 to Yarn 2?
Arguably this is unavoidable if you want to use “contemporary” JS. But again, going back to Rails’ core premise: I am happy to accept the defaults and relieve myself of that configuration and maintenance burden. If I want to make changes, then I can start adding configuration files to effect that.
Was there consideration of moving all the JS tooling into a subfolder / subproject? I’m not sure the ergonomics would be better or preferable, but moving all of the files including the package.json file into the javascript folder might be interesting
I was wondering about the choice of Yarn. I have been using NPM for my package management in another Javascript project and I fail to see the added-value of Yarn.
(I am in no way an advanced user of Javascript so I may not have triggered any advanced usage yet.)
I believe the split between NPM and Yarn started when NPM had less features than Yarn (one of the reasons why Yarn was developed in the first place). NPM before version 5 didn’t have a lockfile, which was a huge issue for repeatability.
It might make less sense now, I don’t have a strong opinion either way.
