envinfo
envinfo copied to clipboard
Config file vs source code file for presets
Looking at PR https://github.com/tabrindle/envinfo/pull/153 made me wonder where the line should be drawn for adding presets.
Would it make more sense to have a file like .envinfo that we could read from to figure out a project’s configuration instead of requiring PRs to the presets file?
I’d be happy to work on a pr adding that if others agree it’d be a good approach to take.
While I do WANT to drive adoption of my project, I had the same thought after reading that issue. I'm ok with a few core projects staying in (CRA, styled-components, apollo, et al), we definitely have to draw a line eventually, and can only do this once we have an alternative route. I can see even core projects wanting their config inline
I agree a file is a good place to do this. Passing that number of configs inline, while possible is not a terribly good idea.
Considerations for the design of this feature:
- size. envinfo is frequently used via npx, so I want to preserve small size for speed of download
- the file having a consistent name and extension. (extensionless dotfiles bother me)
- ability to use a remote config file (fetched via http, possibly a future feature)
- the contents of the config file being similar or identical to config passed inline when using the library directly in js
- somehow declaring compatible versions of config vs versions of envinfo
Feel free to open a PR!
please add this. That would make this project able to support usage in any other lib/project in general. Not just for the handful few projects in that have their key in presets.js
To be fair, I don't think we actually need presets or config files. We (Material-UI) are just publishing our own package (@material-ui/envinfo
) that wraps the programmatic API.
That should be sufficient and is even shorter:
-npx envinfo --preset material-ui
+npx @material-ui/envinfo