* Start of cli docs
* Document the CLI
Also adds support for the `--config` option and `--port` option for the dev server.
* Add tests for --config and --port flags
* Add port to validateConfig
Svelte component resolution wasn't handled correctly during the build.
Note that in the future we need to consolidate a "framework" API, so this stuff is not sprinkled throughout the codebase.
* add dep domhandler imported in in src/build/static
* lint and jsDoc error
* move domhandler to devDep
* chore: add package lock
* escape string jsDoc
* chore: add astro dep in until prism import is refactored
* chore: add snowpack example package lock
* Implement fallback capability
This makes it possible for a dynamic component to render fallback content on the server.
The mechanism is a special `static` prop passed to the component. If `static` is true then the component knows it can render static content.
Putting aside the word `static`, is this the right approach? I think giving components the flexibility to make the decision themselves *is* the right approach.
However in this case we have a special property that is passed in non-explicitly. I think we have to do it this way because if the caller passes in a prop it will get serialized and appear on the client. By making this something we *add* during rendering, it only happens on the server (and only when using `:load`).
Assuming this is the right approach, is `static` the right name for this prop? Other candidates:
* `server`
That's all I have!
* Use `import.meta.env.astro` to tell if running in SSR mode.
* Run formatter
