Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow overriding the output root with a command line flag #1390

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mythmon
Copy link
Contributor

@mythmon mythmon commented May 23, 2024

This can be helpful if you are building in an environment that is different than the configuration file expected. It can also be used to build a project multiple times to multiple directories, such as to run diff on the output to see the effect of a change.

It would however make any "custom" scripting between build and deploy harder, since the output root is no longer as predictable. Perhaps the recommendation here should instead be to make the config file read an environment variable for its output directory?

@mythmon mythmon requested a review from mbostock May 23, 2024 16:37
@mbostock
Copy link
Member

I have been wondering if we should have a more general way of overriding the config. For example config overrides would allow the checked-in configs for the examples to be simpler, while allowing us to still apply a shared example header when building/deploying. I also wonder if such a thing isn’t already possible: maybe a config file that imports and augments another config file? (Maybe relying only on process.cwd?)

@mythmon
Copy link
Contributor Author

mythmon commented May 23, 2024

What if we could "layer" config files? In docker-compose, you can pass --file multiple times to specify multiple configuration files. Each file implicitly extends the one that came before it.

So for this example, we could have an extra file that only specifies export default { output: "override" }. You could then say observable build --config observablehq.config.js --config override.js. Values in override.js would override those from the normal config.

That gets tricky for compound settings like pages. Since our configs are code though, we could have them participate actively in the overlay process:

export default (config) => ({
  ...config,
  // remove all but top level pages
  pages: config.pages.filter(d => !d.path),
});

Here I'm using a "return a new modified object" approach, but maybe it would be simpler to make the interface require mutating the config object. I'm not picky about how exactly the function works.

This might also be able to take care of #1389, if we make the location of deploy.json configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants