Config file vs source code file for presets

[ryhinchey]

Looking at PR #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.

[tabrindle]

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!

[capaj]

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

[eps1lon]

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