| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
* 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>
|
|
|
|
* Add Windows to test suite
* Try implicit URL
|
|
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
|
|
* Parse inner JSX as Astro
This completes the compiler changes, updating the parser so that it parses inner "JSX" as Astro. It does this by finding the start and end of HTML tags and feeds that back into the parser.
The result is a structure like this:
```
{
type: 'MustacheTag',
expression: [
{
type: 'Expression',
codeStart: 'colors.map(color => (',
codeEnd: '}}'
children: [ {
type: 'Fragment',
children: [ {
type: 'Element',
name: 'div'
} ]
} ]
}
]
}
```
There is a new Node type, `Expression`. Note that `MustacheTag` remains in the tree, all it contains is an Expression though. I could spend some time trying to remove it, there's just a few places that expect it to exist.
* Update import to the transform
* Transform prism components into expressions
|
|
|
|
* Improve renderer types
Looking at the render code I noticed that the Component rendering is not typed. This adds that, might help prevent a bug in the future.
* Create the supported renderer type
|
|
|
|
* 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
|
|
|
|
* Compiler cleanup
This is general compiler cleanup, especially around the codegen part. Goals here were too:
1. Make it possible to compile HTML recursively (needed for future astro-in-expressions work) by moving that work into its own function.
1. Get rid of collectionItems and have compiling the HTML return just a source string.
Also not planned, this change gets rid of the different between components and pages. All Astro components compile to the same JavaScript.
* Remove unused node types
|
|
* Allow no config
* Update README
|
|
|
|
This improves the algorithm for searching for pages. It now works like:
1. If pathname ends with /
1. Look for PATHNAME/index.astro
1. Look for PATHNAME/index.md
1. else
1. Look for PATHNAME.astro
1. Look for PATHNAME.md
1. Look for PATHNAME/index.astro
1. 301
1. Look for PATHNAME/index.md
1. 301
1. 404
|
|
|
|
|
|
|
|
|
|
* Fix React import
* Change default export
* Fix :visible dynamic component
* Use colon to alias vue createElement
Co-authored-by: Matthew Phillips <matthew@skypack.dev>
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
This adds `import.meta.request` to pages (not components).
|
|
* Support for custom elements
Now you can use custom elements like so in Astro components:
```html
<script type="module" src="./datepicker.js">
<date-picker></date-picker>
```
These will be resolve relative to the current astro component. In the build these modules are run through the same bundle/minify process as components.
* Remove component from public
* Formatting
* Disable empty fn rule
|
|
* 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
|
|
* Extract Astro styles to external stylesheets
* Require relative URLs in Markdown layouts
|
|
|
|
|
|
|
|
|
|
Previously dynamic component URLs were being resolved client-side in a weird way that only worked during dev. This change makes them handle during compilation, so it works in both (and improves readability of the dynamic import output).
|
|
|
|
* 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
|
matthewp
Matthew Phillips
natemoo-re
Drew Powers
Matt Mulder
Jonathan Neal
duncanhealy
Fred K. Schott
