* Use npm package names to load internal deps
This is necessary so that published Astro components work. These components will be built by esinstall and therefore they cannot rely on `_astro_internal`. The fix is to use npm specifiers everywhere.
* Move most of frontend to internal
* Mark astro/internal/markdown.js as external
* Move markdown stuff to its own package
This moves the markdown stuff to its own package so that we can externalize it in the markdown component.
* Add the changeset
* Improve dev startup by making most dependencies externals
This moves most dependencies to be an `external` for Snowpack, preventing backend deps from going through esinstall.
* Update benchmark times
* chore: add benchmark script for convenience
* fix: update externals to allow renderers
* chore: update benchmark times
Co-authored-by: Nate Moore <nate@skypack.dev>
* Remove create-astro from workspace
* Improve contrast ratio
* Swap blank template for blog template
* Remove counter components from blog template
* Use `latest` astro version
* fix: add svelte plugin for esbuild, remove precompiled svelte components
* refactor: public export map, public types
* feat: add source-map-support to common code paths
* chore: move new "exports" to "imports" map, add internal types
* Include outPath in error logging for bad load status, and drop error stack (#163)
* Include outPath in the error logging for bad load status
* Discard error stack since it seems not useful
* feat: improve build error logging
* refactor: use object param for writeResult
Co-authored-by: Kevin (Kun) "Kassimo" Qian <kevinkassimo@gmail.com>
* 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
* Pass the `mode` through to snowpack
This allows the production packages to be prepared.
* Use snowpack 3.3.1
* Update path to prism loadComponents external ref
* Upgrade to snowpack 3.3.2
* chore(examples): add kitchen-sink
* feat: support children in rendered components
* feat: add support for rendering children in Svelte
* fix: cleanup p/react fragment children
* chore: add @ts-nocheck to svelte files
* chore: update lockfiles
* fix: types
* feat: memoize frontend/renderer/utils
* fix: disable eslint for compiled SvelteWrapper
* fix: add missing dep
Co-authored-by: Nate Moore <nate@skypack.dev>
* Change to import.meta.glob()
Change of plans—maintain parity with Snowpack and Vite because our Collections API will use a different interface
* Get basic pagination working
* Get params working
* Rename to import.meta.fetchContent
* Upgrade to fdir
* 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
* Add support for syntax highlighting of code blocks
* Escape usage of backtick strings
* Add workspace root for snowpack
* Use prismjs/components as an external module
* 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
