Under the Hood
Let’s begin with how the idea came to the mind. One of my friends posted a tweet about this JS confusing file system for ...
For further actions, you may consider blocking this person and/or reporting abuse
For example in Nuxt it is possible to have integration modules (which are distributed as npm package and activated simply by adding entry into
modulesarray innuxt.config.ts) which can inject the most common options todefineNuxtConfigobject and so you can only keep one extra config file (nuxt.config.tsitself) unless you really something extra that cant be achieved like that).Yes, if the module not exist yet, you may have hard times. But you can always try to write your own plugin.
Yes, it is not platform-agnostic, but why not to benefit from a framework? I beleive others will have similar mechanisms to help centralising the config.
I totally agree with the next framework thing but creating platform-agnostic will still remain the bottleneck.
Some of these tools allow for an optional path to their config file. Like eslint has the --config flag. We can have our build scripts use those flags to configure that. Though it would be nice to have it be more turnkey. An environment variable option gets us closer, though it still requires some fussing around. We would want our editors to be able to adapt too.
I think there won't be enough active demand to make this convention happen. And think about breaking changes if someone is using that sort of folder with their own unexpected convention for a "config project" in their repo or something like that. Just playing devil's advocate there. Everything has tradeoffs and risks.
Make an RFC and we'll talk 😛 I suppose this article is close to that but we need more guidance and more voice of authority in the conversation.
I vote for
./.conf/or./.config/If we start asking for it enough and get the largest tools on board, the rest should follow. I'd start with node.
I think the rest weren't able to follow this new convention because of platform agnostic solution, a solution that should exist in the Javascript(JS) ecosystem instead of the framework ecosystem and developing such kind of tool will be a task
What do you mean by the Javascript ecosystem?
We can't simply create an npm module that will solve the problem for every existing and upcoming framework, in order to be backward and forward compatible it's make sense if javascript ecosystem like node bring something as a solution which can become universal, if not wrong!!
That was my suggestion: to start with node. Not another node package, but node-native support of configuration files in a
.confdirectory.That is a bit complex topic as there are so many different tools.
Currently you can use .env file. It can be located anywhere.
With JS it it trivial to create a .JSON config and put it into any location. Can be one configured in process.env.mypackagename.configfilename (in .env file). You end with custom dir - you can also follow Linux ~/etc and ./etc. Npmrc normally is loaded from system global path, then ~/.npmrc then ./.npmrc.
Finally you can run this in a sandbox (docker?) and inject the files. Or k8s and map configmaps.
Then you have the issue of ./src vs./dist. Even worse when creating js from ts and also generating types. And having static content. One option is to have subdirs under src and dist.
Tests. Where to put unit tests, integration tests, fixtures, docs (manual), docs (generated), default confirmation and finally local confirmation override? With docker you could achieve that but it is challenging.
Overall you can get it done easily with proper design and many iterations of refactoring.
What I suggest... well... should I write an article about it? Likely...
I don't think just sweeping it under the rug is the solution, there needs to be less configuration. This is why frontend development is viewed as over engineered and bloated.
There should be a standard file format that defines the project level, it could point to where the other configuration files are, if you still want to have multiple files. The issue that I have had in the past with multiple files is finding which one is causing a bug due to a misconfiguration -- too many different formats and naming conventions.
Yeah, debugging with multiple files make things difficult, and only using those files to configure the plugins is quite a waste of resource(time + space)
Thanks for the article, definitely a good idea, would also be good to create a repository to test this out for a few configuration files
Yeah, seems like a small JS project if able to complete!!!