Closed yhaering closed 4 years ago
Hi @yhaering,
Besides the reasons you mentioned, the config needs to be serializable because it is injected into the React Cosmos UI. ESLint and Babel are server-side tools, but React Cosmos is both server and client side. Two separate configs could fix this, but it's still not ideal because some options are read in both the server and the client.
What if you generate your RC config before starting it? The generated config could be gitignored, or not, depending on your preference. Your cosmos script could look like this:
"scripts": {
"cosmos": "scripts/generate-cosmos-config.js && cosmos --config ./path/to/generated/cosmos.config.json"
Thanks for the quick response.
I thought about generating the config file as well but would consider that a hacky last option ;)
Is it possible to start cosmos using a NodeJS API? I played around with the startPlayground function but did not get it to work properly.
Is it possible to start cosmos using a NodeJS API?
Not really. The flow is pretty easy to follow, so it wouldn't be hard to expose an API. But the config is not received as an argument in the main function, but rather detected inside.
I thought about generating the config file as well but would consider that a hacky last option ;)
It's a hack, or a sophisticated config pipeline 😅
Hopefully this is good enough for you to get going.
I can't see something I could easily patch to make this easier for you at the moment, but I am keeping an open mind regarding:
.js
config module in the future. After all, the (computed) options need to serializable, not the file itself. That said, only a JSON file could be made editable via UI. And btw, the TypeScript config is also a JSON file ;).Thanks so much! :) I will go with the highly sophisticated config pipeline approach for now. Keep up the great work you are doing on this project!
Thank you, and good luck to you!
Came across this when searching for a js option and thought it would be a nice to have!
I've been trying to reduce the number of dotfiles in the root of one of our repos and it would be pretty sweet if we could join cosmos.config.json
and cosmos.overrides.js
into a single cosmos.config.js
.
Just my two cents - keep up the great work!
While i totally understand the reasoning behind following restriction...
...I would love to see a way to allow JavaScript config files to be able to embed react-cosmos in enterprise environments.
In my specific use case we are normalizing building and testing across 50 independent projects in our company with a custom CLI tool. To be able to use react-cosmos in this environment I have to dynamically set the webpack configPath and rootPath inside the cosmos.config.json which is currently not possible.
I looked at the code part that is currently responsible for blocking JavaScript based config files and noticed that the JSON config gets loaded via the NodeJS require function which would automatically allow JavaScript configs that include a default export.
As I said at the very beginning, I can totally understand the intention of this restriction, yet I think the JavaScript ecosystem is way to versatile and complex to restrict tool configuration on simple JSON files. Further more popular tools like ESLint and Babel are going the hybrid approach as well to allow usage in any scenario.
I would love to hear your feedback on this proposal.