ReactTemplate VS Bazel

I've never found CRA makes project management any easier (aside from the first few days after setting up a new project). In the long run it's always been a pain as it prevents you from touching most of the config. Personally I use this ReactTemplate which uses many of the same tools as CRA but with everything exposed and much more sensible defaults so it's easy to configure for whatever you want and nothing is forced upon you.

Most people have only ever used Webpack via CRA which is a terribly optimized config. If you design your own Webpack config it can be so fast that you won't notice it. (Example)

I recommend setting up tsconfig with strict mode enabled and ESLint and TypeScript ESLint rules to be fairly strict. This is a great way to learn with guard rails as it'll slap you when you try to do something which is unsafe or too loosely typed. Here's a reference ESLint config that is frequently updated with any newly released rules that fit well. This happens to be for a TypeScript React project, but you can always trim out the rules from plugins that aren't relevant for you.

Don't forget ESLint. Arguably more important than many of those other things for fixing the common mistakes that most developers make. And note that the recommended ESLint configs are incredibly conservative so you probably want to customize the rules to get much higher quality. An example of one of my recommended React/TypeScript ESLint configs.

And then I have a ton of code-level tools and configs that I use all the time. Many of which are in this React Template if you want to pick through it. There's code spellcheckers, dependency update checkers, extensive linting configs and more.

If you want a reference, take a look at this eslint config for some good rules to use.

If you want a reference, this ReactTemplate is very simple and in many cases can be used as a drop-in for CRA.

No reason to go overkill with a metaframework. All you need is a new build config. That's all CRA is, a collection of configuration files. I choose to just configure what I need myself so I have control over it and can easily customize it and get all of the features and performance that I want if I want it. The content of your app shouldn't need to change just because your build process changes. (If you want a reference, here's the React Template I start with.)

Yeah here's the config from my open source React Template: https://github.com/CreativeTechGuy/ReactTemplate/blob/main/.eslintrc.js

PS: If you are curious, this is my React Template that I was describing above.

Wow, if you curl it, there's a lot of boilerplate code there.

Maybe built using Bazel?

https://bazel.build

Bazel by Google

Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139

This is a problem that Bazel (https://bazel.build) solves in a very convenient way. You can just keep using the paths relative to the repository root, and as long as you properly declare your test needs that file it will access it without problems. Or you can use the runfile libraries to access them too.

When doing research for this lab exercise I looked at both vcpkg and conan. Both are package managers that would automate the installation and configuration of my program with its dependencies. However, when it came to releasing and sharing my program my options were limited. For example, the central public registry for conan packages is conan-center, but these packages are curated and the process is very involved. There was no way conan-center would accept a class project like mine. Alternatively, I could host a conan package on a public Artifactory repository, but accessing the package requires users to add the repository to their conan remote. This already sounded like too many steps to expect regular users to follow - I already haven't setup any conan remotes, there's no way I could expect regular users to know about conan remotes, let alone have conan installed on their system. After discussing with people online and consulting my instructor, I ultimately decided to do a GitHub release. However, in the future I was encouraged to look into using CMake or bazel.

NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇

> None of this solves C's only REAL problem (in my opinion) which is the lack of dependency management.

Bazel solves this really nicely, I know some people have strong opinions on it but I cannot recommend it enough

https://bazel.build/