* Add example blog
* Add author data
* Improve navigation
* Style nav
* Add friendly error message
* Throw error if import glob used for non-Markdown files
* Use import.meta.collection() API instead
* README fixes
This adds astro/components/ and moves the Prism.astro component into there. So to use in a project you can do:
```html
---
import Prism from 'astro/components/Prism.astro';
---
<Prism lang="html" code={`<html> ... </html>`}
```
* Fix complex MDX parsing
This allows fully MDX support using the micromark MDX extension. One caveat is that if you do something like use the less than sign, you need to escape it because the parser expects these to be tags otherwise.
* Move micromark definition
* 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
* Convert CSS Modules to scoped styles
* Update README
* Move class scoping into HTML walker
* Fix SSR styles test
* Fix mustache tags
* Update PostCSS plugin name
* Add JSDoc comment
* Update test
* Add support for React components.
This adds support for react components via a new `extensions` config in astro.config.mjs. In the future we can extend this to do things like look at the import statements, as Snowpack does.
* Fix the tests
* Begin debugging
* Initial tests set up
This adds tests using uvu (we can switch if people want) and restructures things a bit so that it's easier to test.
Like in snowpack you set up a little project. In our tests you can say:
```js
const result = await runtime.load('/blog/hello-world')
```
And analyze the result. I included a `test-helpers.js` which has a function that will turn HTML into a cheerio instance, for inspecting the result HTML.
* Add CI
* Remove extra console logs
* Formatting
