Javascript Packages & Configuration

I recently completed a code test for a job application and decided to use Next.js. It went fairly well, however I spent so much time just modifying configuration files and here are some rambling thoughts on that.

These are all the config files required to run the app:

• enzyme.js
• tsconfig.json
• jest.config.js
• next-env.d.ts
• package.json
• jest.tsconfig.json

Apart from Jest, this is a default install. I could have easily added Webpack config, Next config, Prettier, ESLint and TSLint. Not to mention css pre-processors or other css-in-jsx that aren’t included in Next.

In the app’s defence, it’s trying to do a lot. It’s running Javascript through the Babel transpiler for it to run in the browser, it’s type checking (when it works!), it’s running Jest tests in a Node environment that’s simulating the browser with JS DOM and Enzyme and finally it’s running an Express server for it to do server side rendering …phew!

Rather than re-inventing the wheel, a few frameworks try to solve all this configuration for you by bundling all these great packages together. But that never really works out for a few reasons:

• Packages included are updated over time. This causes incompatibly issues with each other that result in issues unable to be resolved until other packages release a fix.
• They try to solve so many problems that users of the framework/library may or may not even have. For example GatsbyJS, the React static site generator was really great at first. But it started piling in other packages like GraphQL that I had absolutely no need for.
• They start by creating something that they would use, or have been using which is based on what they believe to be best. This results in various opinions seeping in which they they try to combat later with a half-baked plugin approach.
• Stack traces become unbearably huge and hard to grok.

So what’s the solution? Off the top of my head:

• Keep it simple, stupid.
• Only include packages and config required to achieve the base goal. No more, and no less.
• Make the decision: Is it extensibile or not? If so, make it plugin focused from the start, otherwise, set a limited scope on what it aims to achieve and stick to it, opinions and configuration included.

I’m at the stage where I am happy for someone to make these, let’s face it, often trivial decisions over linting config or what’s the best css-in-jsx library. I’d rather have something just work!