withastro / astro Goto Github PK

The web framework for content-driven websites. ⭐️ Star to support our work!

License: Other

JavaScript 42.04% TypeScript 54.72% Svelte 0.15% Astro 2.56% Shell 0.03% CSS 0.08% Vue 0.23% Dockerfile 0.02% Roff 0.02% MDX 0.16% SCSS 0.01%

static-site-generator blog islands components node browser server hybrid universal astro

astro's People

Contributors

Stargazers

Watchers

Forkers

npup itskitto karbon0x kkpalanisamy therakeshpurohit itsdouges kevinkassimo yuto343 zhenghaiyang kaisermann bradlc jhuleatt geektrainer ineshtickoo ange-rodriguez drivenbyvalues tjcuevas mnemosdev geckotang gauravrajsharma 11khoa artur-swoboda whjvenyl rhnsharma tylergaw eyelidlessness tony-sull andikod backlineint anjathiart jihchi narender2031 marmiz albinkc wjnbreu jeffjose mutazalhawash daveek tom-sapletta-com sibbng jasikpark technikhil314 briannhinton xhfkindergarten theianjones tony-navillus hanawa02 simondebbarma one-aalam frantchessico tbor8080 sajjadanwar0 smilenew sixtomay cnjock carljustineoyales ibrahim-isah randpharoah matsdahlin wangjacker marcisbee johnnyma sikemausa jqk6 erikvold austincrim akellbl4 lyrl neulchance adamochayon appgrader radiosilence zakcutner silveirado lokhmakov yeukfei02 burnedchris sherrywilly timeshift92 outcastgeek alvarlaigna stenehall madx shreeshbhat braden-preston mihkeleidast josiahwiebe colbygarland devsmitra bryanpan342 sarthaksj kerod-fresenbet-gebremedhin2660 juan-bustos ceo0x spread0x cyberflamego benjamin-piper b0yblake alexander-guesnon jaipise

astro's Issues

Support complex `import` cases other than `default` exports

src/components/counter.tsx

import React, { useState } from "react"

function Counter() {
  const [count, setCount] = useState(0)
  const increment = () => setCount((c) => c + 1)
  return (
    <button type="button" onClick={increment}>
      {count}
    </button>
  )
}
export { Counter }

src/pages/index.astro

---
import SiteLayout from '../components/site-layout.astro'
import {Counter} from '../components/counter.tsx'
---
<html>
<body>
    <p>awesome website?</p>
    <Counter:idle />
</body>
</html>

This fails with this error:

[executing astro] Error: Unknown Component: Counter
    at Object.enter (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/codegen/index.ts:592:19)
    at SyncWalker.visit (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/estree-walker/src/sync.js:49:16)
    at SyncWalker.visit (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/estree-walker/src/sync.js:79:18)
    at SyncWalker.visit (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/estree-walker/src/sync.js:79:18)
    at walk (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/estree-walker/src/index.js:20:18)
    at yt (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/codegen/index.ts:539:3)
    at ht (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/codegen/index.ts:677:16)
    at bt (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/index.ts:50:10)
    at $e (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/index.ts:113:14)
    at tn (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/compiler/index.ts:126:18)
    at Object.load (/mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/snowpack-plugin.cjs:23:22)
    at runPipelineLoadStep (/mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:122225:32)
    at Object.buildFile (/mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:122424:24)
    at /mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:163081:37
    at FileBuilder.build (/mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:163093:32)
    at Object.loadUrl (/mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:182113:17)
    at load (/mnt/c/Users/me/Projects/my-astro-project/node_modules/snowpack/lib/index.js:181722:28)
    at Le (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/runtime.ts:88:17)
    at Server.<anonymous> (file:///mnt/c/Users/me/Projects/my-astro-project/node_modules/astro/src/dev.ts:31:20) {
  __snowpackBuildDetails: { name: 'snowpack-astro', step: 'load' }
}

💡 RFC: provide hook for custom markdown renderer

since MD is built-into Astro, it would make sense to provide this hook via some Astro config (or: let you provide a custom Astro plugin that takes over responsibility for rendering MD to HTML)

via discord

Are logic blocks supported in astro files?

First, congratulations on building the right kind of website foundation. 🙏

Are logic blocks supported in astro files? My understanding is that astro files might be based on svelte files, and so I had hoped to try this out.

Here is my humble astro page:

---
let cats = [{ name: "Meowser" }, { name: "Catatat" }, { name: "Mr. Kitty" }];
---

<html>
  <title>My Kitty Friends</title>
  <body>
    <h1>My Kitty Friends</h1>
    <ul>
      {#each cats as cat}
        <li>{cat.name}</li>
      {/each}
    </ul>
  </body>
</html>

Unfortunately, my perfect page renders with a 500 status and the following error:

Expected as (10:21)
 8:     <h1>My Kitty Friends</h1>
 9:     <ul>
10:       {#each cats as cat}
                            ^
11:         <li>{cat.name}</li>
12:       {/each}

Am I doing something wrong? Is this unsupported? Something else? And if so how can I help? 😄

Astro Version: 0.0.5

Incorrect expression evaluation when multiple JSX children exist in mustache

For

<html>
  <body>
    {
      false ? <h1>TRUE</h1> : <h1>FALSE</h1>
    }
  </body>
</html>

It seems that Astro always yields TRUE for built pages.
It is funnier when it is compared to

<html>
  <body>
    {
      false ? "TRUE" : "FALSE"
    }
  </body>
</html>

which would yield FALSE as expected.

This is due to current interface of Expression
https://github.com/snowpackjs/astro/blob/a7185735da7413e132f313ff5086db74304d7654/src/parser/interfaces.ts#L52-L59
which only has a single codeStart and codeEnd, and in that during codegen
https://github.com/snowpackjs/astro/blob/a7185735da7413e132f313ff5086db74304d7654/src/compiler/codegen/index.ts#L522-L529
which assumes a single child.

I have done a branch locally that seems to have fixed this issue. Looking forward to do a PR.

Markdown with variable content use to work

Hi!

---
const content = '# foobar';
---
<Markdown>{ content }</Markdown>

was working on 0.10.0 not on 0.11.0

It's a regression or Markdown is not supporting this anymore?

Incorrect file formatting in astro-create script

When running yarn create astro ./my-astro-project it printed the path as ././my-astro-project incorrectly. It should print as ./my-astro-project

Layouts as components

Layouts are an interesting problem because:

They are necessary for markdown files to be pages.
They aren't necessary for HMX pages, but can still be useful.

Our current approach to layouts has the following downsides:

HMX pages do not have full control over their output HTML.
1. Which means special syntax is required to put parts of an HMX page into parts of the parent layout.
2. A page cannot set the <html> element (or any attributes on it).
3. A page cannot set the doctype (less important these days but conceptually it speaks to the underlying issue here).
4. A page cannot omit head/body tags. (again, not important, but speaks to the problem).
HMX is not a true superset of HTML because you cannot paste arbitrary HTML into an HMX file and have it work.

One of the goals of HMX was to provide a light and familiar syntax that is mostly just HTML, with a couple of exceptions in capital-Component tags and JSX expressions. Layouts as they currently are add this third concept with special rules for what you can and cannot due.

Component approach to layouts

I'd like to propose an alternative to layouts as we currently have them. What if layouts were just components like any other? In a page you import a component and use it. With the basic primitive of slots you have the power to define what slots the layout component needs and name them whatever you want.

This approach has the following upsides:

You can use React, Vue, etc. components as layouts!
No special head/body handling within the compiler. The HMX compiler doesn't need to know about head and body tags at all. The markdown to HMX compiler does, of course, but it can compile to component usage. (see next section). This means that HMX pages have full control over the HTML they produce. They can use layouts or not.
No need for a special layouts folder. Layouts are just components, they can go in the components folder (having a special folder is not a bad thing for organization, but it's not a requirement here because there's nothing special about layouts).
Alternative patterns to layouts are possible. Instead of creating a layout you can just have special components that you use for inserting tags into the head.

Markdown pages compiled to layout usage

You could see markdown being transformed to HMX that looks a little like below. This is the same way an HMX page that uses layouts could be authored.

post.md

<script astro>
  import Layout from '../layouts/blog.hmx';
</script>

<Layout>
  <Fragment slot="head">
    <title>My Blog Post</title>
    <link rel="stylesheet" href="/styles/blog.css">
  </Fragment>

  <div slot="content">... blog post content here</div>
<Layout>

layouts/blog.hmx

<!doctype html>
<html class="home-page">
<head>
  <meta charset="utf-8">
  <slot name="head"></slot>
</head>
<body>
  <header>
    <h1>Matthew's blog</h1>
  </header>

  <slot name="content"></slot>
</body>

HMX pages that don't use layouts

An HMX page could be written like this, to solve the problem of things like common head elements without the wrapper layout component. This is just intended to demonstrate that layouts are optional and the same problem they solve can be done other ways (this is typically how I do things with 11ty personally):

pages/news.hmx

<script astro>
  import CommonMeta from '../components/meta.hmx';
  import CommonStyles from '../components/styles.hmx';

  import SiteHeader from '../components/site-header.hmx';
</script>

<!doctype html>
<html lang="en">
<head>
  <CommonMeta />
  <title>My page<title>
  
  <CommonStyles />
  <link rel="stylesheet" href="/styles/news.css">
</head>
<body>
  <SiteHeader />

  <h2>Our News</h2>
  ...
</body>

Do not require `<head>` and `<body>` elements for transformers

We really shouldn't be requiring <head> and <body> elements [in transformers/optimizers] as those are not required in HTML. What we should be doing in a case like this is if there is not a head, find the first non-head element (so anything that's not one of these: https://htmlhead.dev/#elements) and inject before that element. The browser will parse it as inside of the head. We could create a utility to make these easier for transformers to do.

Originally posted by @matthewp in #231 (comment)

Create .gitignore for starter templates

I think when creating a project with npm init astro ./new-project a .gitignore file should be in there containing the node_modules folder.

support live reloading

not sure if this is not working for me or if this is not supported yet - but it would great to have similar dx to snowpack with live reloading on save.

node 14.17.0
astro 0.10.0

Text background color on hover not shown for new landing page

From comments in #95:

The text link disappear on hover

This behavior only happens in Safari, but not in Chrome. When a:before (used to draw the green box) content is empty, its width and height are both 0 for Safari. The reason is that inset: 0 (equivalent to top/right/bottom/left: 0) is NOT supported for Safari: https://caniuse.com/?search=inset

https://github.com/snowpackjs/astro/blob/ea33d7b2ab30f6434986bb0d8671e7f681076268/www/public/global.scss#L78

Originally posted by @kevinkassimo in #95 (comment)

Maybe we should use the more conservative top/right/bottom/left combinations here. I'm unable to make a PR directly myself due to no permission + no forking allowed.

Ensure pages are fully static

Doing some early brainstorming for "dynamic page" support, and I realized that we'll probably have an issue with how to build your site when many pages are static, but some are dynamic. If a page is known to be static, we can build it once at build-time (as we do today) and then serve it in production as a static file.

Next.js does this with getStaticProps and getServerSideProps. If you use getServerSideProps(), your page is dynamic. Otherwise, it's static!

It's obviously too early to do anything big here, but since we're currently 100% static I'd like to put in some guarantees if we can. For example:

Don't grant a page access to the URL querystring or search values from the current requesting URL, since those can change at any time. Our build command would hit those pages with the simplest path-only URL anyway, so this would be a good idea regardless.
anything else?

@drwpow maybe you're already targeting this as a part of cleaning up import.meta, but I figured I'd surface here.

Module scripts src relative path not prefixed by `.` is not correctly rewritten during build

For

https://github.com/snowpackjs/astro/blob/d2337e70239137700447dd46d5bd70de38a0a8ae/examples/snowpack/astro/components/Nav.astro#L351

If you replace it with <script type="module" src="docsearch.js"></script>, the source path would not be rewritten and kept as docsearch.js, thus making the output page not able to load this script.

This is due to

https://github.com/snowpackjs/astro/blob/d2337e70239137700447dd46d5bd70de38a0a8ae/src/compiler/transform/module-scripts.ts#L29

and thus would miss relative paths without . prefix and not performing the rewrite (technically I believe only /path-absolute paths should be ignored). To fix this, probably we can do

if (!src || src.startsWith('/')) {

(I had a local branch for this that seems working, but since the project could not be forked I could not make the PR I'll just leave my investigations here)

Hydrating Svelte components doesn't happen

With the current implementation of SSR for Svelte, it refuses to hydrate the component. Svelte points out in the console that you didn't pass hydratable: true

Doing so is not possible currently, because Astro is using the component's render function and it doesn't support the option. There are two solutions Svelte provide which they have their own problems too:

Using the svelte register which can set the compiler options for the render function, but it doesn't run in an esm based environment because it uses require.extensions.
Using the compile function Svelte provides which accepts the hydratable option directly, but it doesn't return the html string.

So maybe a little extra work needs to be done for Svelte. There are some discussions about it in the Svelte issues too that is worth checking out.

💡 RFC: Internationalization

Would love to start a conversation around internationalization. For us here it's a requirement and I believe that is the case for many companies as well. Every website we ship is localized to at least 3 languages.

It's a big and complex system and I guess that's why a lot of frameworks leave it to plugins and external packages to deal with that. NextJS recently implemented this feature but it lacks SSG support.

One thing it's really nice and we could probably take a lot of inspiration from is how it's set up. In a nutshell:

Set the locales on the config
getStaticPaths receives that list of locales and the developer pick and choose which to generate

Would love to help implement this feature but most of all would love to hear from the more experienced maintainers what are your thoughts on this. If possible maybe point me in the right direction as to where to begin.

Fix: Setup a new project with nodejs 15/ 16

environment:

nodejs v15 or newer
macos or ubuntu 20

call command:

npm init astro@shhhhh

Hooks and shortcodes

Hello thanks for good framework, maybe can add hooks and shortcodes as elderjs?)

typo "dislplay" in renderer.ts

Hi, there is a typo dislplay in src/frontend/render/renderer.ts line 34.

[RFC] Mega Astro styling handling

This will be a working proposal. This will be edited as feedback is received/ideas are explored. Expect the syntax here to change (also for comments to refer to something no longer referenced here)

Problem(s) to solve for

Global CSS is global (won’t go into full explanation here, but CSS Modules thinking, yada yada)
People want nesting and a few other comforts afforded by PostCSS / Sass
Add ability to ship all styles outside of JS (either inlined in HTML, or via <link> tags)
Users need to be able to critically inline CSS when needed
Users should also be able to generate one CSS bundle of all their styling so the browser can do it‘s thing and cache it well

Proposal

HMX Styles

Default behavior

<style></style>

Outputs CSS with browser prefixes (configurable with a browserslist)
CSS Module local scope by default (must opt-in to :global)
Minified in production
Bundled into the primary .css file that gets loaded via a <link> tag in <head> (it’s named & loaded for you; no work/config on the users‘ part)
(Future feature) Specify bundle name with bundle="mystyles.css"

Sass support

<style lang="scss"></style>
<style lang="sass"></style>

Same as above, but with ✨ Sass ✨

Inlining

<style inline></style>

Works for CSS and Sass
Inlines the styles right then and there in HTML.
This isn’t the default behavior because for people who aren’t being intentional, this will blow out the HTML. Only critical CSS should be inlined, and if people don’t know what that is, then it’s better they blow out the size on one cached .css file, then blow out the markup length on every page rendered.

Importing

<!-- Make network request to load (don’t transform) -->
<style>@import "…";</style>

<!-- Proposal: bundle CSS file -->
<style>@use "myfile.css";</style>

<!-- Proposal: inline CSS file -->
<style inline>@use "myfile.css";</style>

For @import, we will let the browser request that file so that we don’t ruin caching. We will, however, try and resolve that file if it’s local (ignore if global).
(Future feature) @import can import from node_modules and that will get loaded as its own .css file for caching
@use is proposed from Sass for the following reasons:
- It can handle pure .css files as well as Sass
- It doesn’t overburden @import for when users really do want an additional (cached) network request
- Sass already has stellar deduping & bundling support
- We’re making it clear that Sass is doing the work, not us.
- Potential downside: Sass may throw a compile error when using @use. But this should never happen with valid CSS (and if it does, the compiler error should be clear enough to point out the problem).
  - To build off this, CSS compile errors may not be a bad thing? It happens in JS; letting the user know they have bad styles may be a feature, not a bug

JS Styles

CSS Modules

When imported in JS, CSS Modules is disabled by default unless they use the .module.css extension (same behavior as Snowpack).

SSR components

import 'style.css';                          // Included in CSS bundle
import url from 'style.css';                 // Also bundled, but link to CSS path is included in JS
import * as Styles from 'style.module.css';  // Only works with .module.css. Bundled, with CSS class names exported to JS

Dynamic components

Dynamic components should probably work the same way as SSR components—include in bundle? On the fence about this

Summary

So in summary, these are the decisions we’re making, and the tradeoffs:

Styles will be automatically bundled into one .css file for users
In .hmx files, CSS Modules local scope is on by default
When imported via .js(x) files, CSS Modules is off by default (unless they use a .module.css extension).
Critical CSS support is built-in, however it’s opt-in with <style inline>
- It‘s opt-in, for example, so users don’t inline all of Tailwind.css for every HMX component, on every page
CSS is bundled by default.
- Pro: good caching story, lightens HTML payload, browser-optimized
- Con: additional, blocking, network request to retrieve styles on cold hit
- The alternative—inline by default—would mean one fewer network request, but rendering wouldn’t be significantly faster if there’s too much inlined styles (it may very well have the opposite effect).
- Con: styles may be bundled out-of-order, however, this should be mitigated by CSS Modules being on by default. And shouldn’t be a problem unique to us; if a user has conflicting styles then that’s more on their end

pnpm support

Trying to use pnpm in an Astro project, I get errors of missing packages that I'm not even using:

(node:5647) UnhandledPromiseRejectionWarning: Error: Package "preact-render-to-string" not found. Have you installed it?

When I install that, it'll say the same thing about Svelte packages.

At the moment, it seems like Astro relies on packages being hoisted, ergo, the default behavior of npm and Yarn 1. That's not the case with pnpm:

An LSP?

I'm not sure if this is too early to suggest, but is it possible to transform the currently built VS Code language server to be IDE agnostic.

The current setup makes it impossible to integrate Astro with other text editors.

An LSP would make other developers support virtually any other text editor.

[BUG] after build

after build svelte component as

<Test:load/>

give current error

[New Framework] Lit SSR

I did a proof of concept of Lit working with their new SSR support. It's in this branch: https://github.com/snowpackjs/astro/tree/try-lit

Some stuff missing:

Doesn't rehydrate
No support for dynamic variants.

Tweeted about it: https://twitter.com/matthewcp/status/1383120447609405440

Some feedback:

Desire to use the tag name instead of the PascalCase component naming convention like with other frameworks.
- Note that if we did this we would need a way to differentiate between custom elements that should be server rendered and those that should not. I think we should not server render lower case tag names by default, they should be treated as simple HTML. However some sort of :static property might be a way to opt-in.

Markdown code blocks lead to an error

Description:
When serving Markdown files with a code block and using frontmatter with a layout variable astro shows an error page.

Steps to reproduce:

Create a blank astro project `npm init astro ./astro-blank``
cd astro-blank
Create a markdown file in /astro-blank/src/pages/ with the name `my-markdown.md``
Put the following content into the markdown file

---
layout: ../layouts/main.astro
---

# My Markdown

## Some source code 

```
{ 
  "key": "value"
}
```

Create a layout file in `/astro-blank/layouts/main.astro``
Start astro with npm start
Access localhost:3000/my-markdown

Additionally I tried to use

```json

```html

which also lead to a different error.

Current Result:
An error page will be displayed like this:

Stack trace:

[executing astro] Error: Transform failed with 1 error:
<stdin>:1:5: error: Expected ";" but found ":"
    at failureErrorWithLog (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:1275:15)
    at /Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:1094:33
    at /Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:576:9
    at handleIncomingPacket (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:665:9)
    at readFromStdout (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:543:7)
    at runServiceSync (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:1591:3)
    at transformSync (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/esbuild/lib/main.js:1421:3)
    at compileExpressionSafe (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/codegen/index.ts:260:18)
    at Object.enter (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/codegen/index.ts:564:22)
    at SyncWalker.visit (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/sync.js:49:16)
    at SyncWalker.visit (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/sync.js:86:11)
    at SyncWalker.visit (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/sync.js:79:18)
    at SyncWalker.visit (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/sync.js:79:18)
    at SyncWalker.visit (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/sync.js:79:18)
    at walk (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/estree-walker/src/index.js:20:18)
    at compileHtml (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/codegen/index.ts:547:3)
    at codegen (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/codegen/index.ts:724:16)
    at convertAstroToJsx (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/index.ts:44:10)
    at convertMdToJsx (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/index.ts:84:10)
    at transformFromSource (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/index.ts:98:14)
    at compileComponent (file:///Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/src/compiler/index.ts:110:18)
    at Object.load (/Users/ewatch/Development/JavaScript/astro/astro-blank/node_modules/astro/snowpack-plugin.cjs:23:22) {
  errors: [
    {
      detail: undefined,
      location: [Object],
      notes: [],
      text: 'Expected ";" but found ":"'
    }
  ],
  warnings: [],
  __snowpackBuildDetails: { name: 'snowpack-astro', step: 'load' }
}

Expected Result:
A proper HTML page with a code block not being interpreted will be displayed.

Analysis:

In general Markdown will be converted to JSX and produce an html block like the following for the above code snippet and try to execute expressions in the template through the method convertMdToJsx
The convertMdToAstroSource (which is called inside the convertMdToJsx method) converts the following markdown:

```
{ 
  "key": "value"
}
```

to this HTML block:

<pre><code>
{
    "key": "value"
}
</code></pre>

The convertAstroToJsx uses the astro-parser which identifies the { as opening bracket for logic and marks this as MustacheTag as well as "key": "value" as Expression which will be tried to be compiled through the 'Expression' branch of the compileHtml method which is called by the code generator codegen.

Possible Solutions (not tested yet):

Converting { and } to HTML entities inside <pre><code></code></pre> Blocks
Replacing the code parts in markdown with something different and after compileHtml, replacing them back.
Looking into the projects https://github.com/pngwn/MDsveX or https://github.com/AlexxNB/svelte-preprocess-markdown might also provide a solution

Logo! Brand!

what is your #personalbrand ? What is your #mood?

FIGMA DOC: TODO

Error starting blog example

When calling npm run start from the current blog example, the server will not start and the following error is displayed.

Error: Package "canvas-confetti" not found. Have you installed it?

Shouldcanvas-confetti be added to the package, or is something else supposed automatically install the missing dependency?

Astro version: 0.0.5 (at commit 687ff5b)

RFC: renderer plugins

This may be premature, but Astro offers almost everything I’ve wanted in a web [meta-]framework:

Component oriented dev experience
Supports JSX
Built with established/emerging industry standard tooling
Trivial partial hydration
Many batteries included for varying build preferences
Component library-agnostic
At a glance observation: great defaults, lots of clear thought went into providing wonderful DX without imposing build tool config hell

I also think it’s well positioned to check the one large-ish remaining checkbox on my list:

Actually bring your own framework

I already mentioned this to Nate: I want to try this with Solid (I’d love to @ Ryan here but I’m not sure how that would work in a private repo, but this project should definitely be on his radar), another performance-obsessed library supporting JSX, but currently lacking support for partial hydration.

I thought I was going to spend most of my initial early access time tinkering with using this clever bit of machinery. But I did what I always do and read through most of the source. (It’s some of the best I’ve seen in a web context by the way!)

As I would’ve hoped, the current BYOF offering works by abstracting each respective library’s interfaces behind a common one. This is an excellent design for the current set of supported component libraries.

My naïve thought seeing that was “oh, adding support for Solid would likely be trivial-ish and a great first contribution!” Taking a little hammock time led to: this design also provides a good foundation for a plugin architecture.

Proposal

Define the existing renderer abstractions as an explicit interface.
Identify any other renderer-specific internal behavior.
Design clear, consistent interfaces for known-common patterns.
Extract anything identified in this process into renderer plugins, included in Astro by default (or as optional peer dependencies).
Provide and document an experimental/alpha API for external renderers.
Implement support for Solid (or any other library the Skypack team might want to include) on that API as an example/exercise of the initial design.
Red green refactor 🚀

Risks

This is a big ask for a young project and a small team with a lot going on. It feels like a good fit for the project, but I’d be remiss if I didn’t recognize the risks I see upfront:

Like I said: young project, small team. Taking on any major unplanned feature work likely takes away from planned feature work. (That said, y’all have a great reputation at this point of shooting for the stars)
Supporting arbitrary renderers might be a bad API. New libraries might come along with novel concepts that don’t fit and either the API grows a bunch of hard to rest ? types or those libraries get disappointing second-class treatment.
A “contrib”-first ecosystem can put a huge burden on maintainers. Lots of projects have abandoned this model because it was too onerous and caused a lot of confusion when third party dependencies varied in quality.
The intersection of the last two: supporting arbitrary renderers might be burdensome for something likely to be niche.

That said:

✋ I wanna help

This project is something I want to use, support and promote. I’m big on contributing to open source. I’d be happy to participate in this effort (and others as they come to my attention) from a personal investment perspective alone.

can't be installed from tarball

hey all! astro looks really cool, thanks for the preview invite!

playing around with it locally, I wanted to simulate installing from npm by building a tarball (yarn pack), but it's missing a few required files and dependencies (the astro binary isn't included).

Here's a patch that fixed the issue locally (I can't create a PR since forking is disabled):

0001-fix-package.json-so-astro-is-installable-from-a-tarb.patch.txt

edit: I also had to comment out this line in Snowpack for the JSX runtime to work. it seems that Snowpack isn't able to resolve all files in the /_astro_internal mount when its inside node_modules

Error on Windows after creating new project

I get this error when I try to run the start or build script:

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
 ERROR  Command failed with exit code 1.

If it helps, running Windows 10 with PowerShell, but it looks like a path handling issue

My workaround for now is using WSL

EDIT: I noticed that the astro version in the new project was at 0.0.9. I updated it to 0.0.12, but the error still happens.

Runtime svelte missing after running build

After running npm run build and serving the output files (/dist) runtime/svelte fails to load making svelte components unresponsive to user interaction.

This seems related to this PR (#151)

Info

Request URL: http://192.168.1.100:5000/_astro_internal/runtime/svelte.js
Request Method: GET
Status Code: 404 Not Found

Testing this PR (#151) changes locally against a newly created and standalone Astro project seems to do the trick and the components become responsive.

Versions

RFC: Explore alternative `props` API

Currently, .astro files expose component props in the Svelte-style, using the export keyword. While this might be familiar to Svelte users, it does overload a keyword that JavaScript uses for other purposes. Any other ideas that might make sense here? (Note: we might stay with what we have! Just wanted to open the floor for suggestions.)

This is a pretty confusing/surprising API. Typically export provides data to other modules, but this inverts that. I’m not sure I have a better solution in mind, but I’ll think on it if there’s interest on the Astro team.

Originally posted by @eyelidlessness in #137 (comment)

Blog example missing `buildOptions` in `astro.config.mjs` file (RSS error)

Hi guys, nice work with this project and I'm enjoying the examples so far.

Do you have any preference regarding contributing and the best way to provide help and feedback?

Quick note, currently, when running the blog example I get an error:

[build] ! building pages...
[generate] Error: [$posts.astro] createCollection() tried to generate RSS but "buildOptions.site" missing in astro.config.mjs

Updating the astro.config.mjs to the following fixes it:

export default {
  buildOptions: {
    site: 'https://muppet-blog.github.io/',
  }
};

I'd happily submit a PR but ATM forks are disallowed so I've submitted this issue. Hope this helps someone.

`createCollection` API does not account for nested content

Given a file structure like the following:

/src/pages/
├── /docs/
│   ├── v0.0.0/
│   │   └── index.md
│   └── v0.1.0/
│       └── index.md
└── $version.astro

Astro.fetchContent('./docs/**/*.md') throws

[generate] Error: Error: Not Found (/_astro/pages/index.md.js)
    at xr (file:///Users/nmoo/Developer/snowpackjs/astro/packages/astro/src/build.ts:116:11)
    at file:///Users/nmoo/Developer/snowpackjs/astro/packages/astro/src/build.ts:222:42
    at async Promise.all (index 0)
    at qt (file:///Users/nmoo/Developer/snowpackjs/astro/packages/astro/src/build.ts:215:5)
    at Pr (file:///Users/nmoo/Developer/snowpackjs/astro/packages/astro/src/cli.ts:15:15)

If I do add an index.md file to the root, it does not throw, but all the index.md files are output to a single index.html route.

💡 RFC: Compiler API

We would like to add .astro components support to our products (divriots.com)
Do you have an API already I can use ? in browser ?

If this helps: We just need the raw translation to js/ts. We already have TS/babel/JSX/CSS/SASS/CSSModules processing in the build pipeline... which would require less dependencies on your end if we can pull this off.

Cheers

💡 RFC: SSR

Our current intention is to launch Astro as a static site builder. That means all pages are built to static HTML, and no support for dynamic server-side routes.

But, there seems to be a lot of community interest in supporting dynamic routes & pages. If there's enough interest and anyone willing to help us with an implementation, then I'd love to start putting together an RFC for experimental support. If we put this behind an experimental flag to start, then I don't think it interferes with our "static site builder" launch story.

Anyone interested in helping spec out an RFC?

Some pieces that need discussion / fleshing out:

Dynamic pages: can we borrow from Next.js's file based routing? /pages/[id].js, /pages/[...id].ks, etc.
Dynamic props: how does a page register as dynamic? Something like getServerSideProps?
Deploy targets: In addition to a Node.js server deployment, I really want us to have a good Cloudflare Workers story. SvelteKit too the approach of having different "adapters" for Node, Deno, etc. Could we do the same?

[RFC] RSS Feeds from Collections

Main gist

Building off the collections API (taking content either from local Markdown, a headless CMS, or combining both), each collection should have its own RSS 2.0 feed. For example, your $posts.astro collection will generate a feed at /rss/posts.xml. This is very useful to content-driven sites, and could even power things such as a podcast site.

In fact, with podcasting being very popular, that was the main design goal here: support a podcast RSS feed. This could work for blog RSS feeds too, but at the current time I believe podcasts are more ubiquitous than RSS readers. Not that I don‘t miss Google Reader, but thems the breaks 🤷🏻

Syntax

Because Astro needs to build the collection itself, this proposes a rss addition to createCollection(). We basically ask for all the item info we need:

// ./astro/pages/$posts.astro

export let collection;

export async function createCollection() {
  return {
    data() { /* data fetching from local *.md, or remote API */ },
    rss: {
      // basic data is supported…
      title: "Recent Blog Posts",
      description: "My blog posts",
      xmlns: {
        g: "http://base.google.com/ns/1.0",
        itunes: "http://www.itunes.com/dtds/podcast-1.0.dtd"
      },
      // …but you may also insert additional tags as well (freeform, because we don’t want to restrict you):
      customData: `
<itunes:category text="Technology" />
<itunes:title>Syntax</itunes:title>
<g:image_link>http://www.google.com/images/google_sm.gif</g:image_link>
      `,
      /** How each individual item will appear in the feed */
      item: (item) => ({
        // "item" is an individual item from the array you returned in `data()`.
        // "item" may be any shape, but it’s something you control in your source files and/or the data() function itself.
        // The keys of this object match the tags returned (e.g. `title: item.title` generates `<title>My Blog Post</title>`)
        title: item.title,
        link: item.url,
        pubDate: item.published_at,
        summary: item.summary,
        // arbitrary data also supported here, too:
        customData: `
<itunes:duration>${item.duration}</itunes:duration>
`
      })
    };
  };
}

Note: the exact object shape of feed() is TBD, and may be subject to change. This RFC is mostly for the overall mechanism of the feed() function.

This will produce the following at build time in your <head>:

  <link rel="alternate" type="application/rss+xml" href="/rss/posts.xml" title="Recent Blog Posts">

Other notes

This is just a first attempt at it; will adjust as needed.
To start, we’ll only generate an RSS 2.0 feed; we won‘t support Atom 1.0. Though if we wanted to support Atom in the future, we could add an atom property alongside rss.
This will generate one feed for every collection with a rss() function. If rss() is omitted, no feed will be generated. This means you can choose to make only 1 for your primary collection, or you can generate as many feeds as collections (which you may want alternate feeds for certain tags, etc.). The format will always be /rss/[path-to-collection].xml.
The items of your feed should match your data() function. If you don‘t want certain posts to show in your feed, then filter them out in data() (or make a new $feed.astro collection just for this purpose).
customData and item.customData aren’t pretty, but they are flexible. There’s just not really a great way to represent XML in JS, so we don’t
Assume that escaping & cleanup (!CDATA shenanigans) will be handled for you.
Also assume that this will err helpfully if you passed something unexpected (we may not guarantee it’s valid, especially customData, but we will surface obvious errors for easier usage, such as Missing "title")

🐛 BUG: Vue components cannot be nested

Hi team,

What I would like to do, is being able to nest some components and reuse only big component like a card composed by several components underneath

I tried to replicate my issue with a minimal code just here (cc @matthewp )

This one does not work
gqio/astro-local-project-example@027b367

But this one works
gqio/astro-local-project-example@3c9a6db

Thanks Team

[feat] middleware

Hello, will it be possible to add your own middleware, thus the question arises, can I embed a backend for authorization?

Build command fails when using react & vue components

When creating a new standalone Astro project the build command fails when vue or react components are imported/used

Looking at the code it seems that resolvePackageUrl is missing from the frontend options (https://github.com/snowpackjs/astro/blob/main/src/runtime.ts#L338-L346).

Can you help me understand why the frontend config doesn't needresolvePackageUrl in that scenario?

Info

[build] TypeError: resolvePackageUrl is not a function
    at acquireDynamicComponentImports (file:///.../node_modules/astro/lib/compiler/codegen/index.js:224:46)
    at codegen (file:///.../node_modules/astro/lib/compiler/codegen/index.js:583:34)
    at async convertAstroToJsx (file:///.../node_modules/astro/lib/compiler/index.js:32:12)
    at async transformFromSource (file:///.../node_modules/astro/lib/compiler/index.js:80:20)
    at async compileComponent (file:///.../node_modules/astro/lib/compiler/index.js:89:20)
    at async Object.load (/.../node_modules/astro/snowpack-plugin.cjs:24:22)
    at async runPipelineLoadStep (/.../node_modules/snowpack/lib/index.js:122225:32)
    at async Object.buildFile (/.../node_modules/snowpack/lib/index.js:122424:24)
    at async /.../node_modules/snowpack/lib/index.js:163081:37
    at async FileBuilder.build (/.../node_modules/snowpack/lib/index.js:163093:32)
    at async Object.loadUrl (/.../node_modules/snowpack/lib/index.js:182113:17)
    at async load (file:///.../node_modules/astro/lib/runtime.js:21:28)
    at async build (file:///.../node_modules/astro/lib/build.js:208:24)
    at async buildAndExit (file:///.../node_modules/astro/lib/cli.js:9:17) {
  __snowpackBuildDetails: { name: 'snowpack-astro', step: 'load' }
}

Versions

Load components from local node_modules

Hi Team,

I have 2 projects one astro-hw with astro and one (@acme/components) bunch of components
I have 1 astro file with trying to import a component from @acme/components/button.vue

The latter project is not yet published, it has been declared as dependency in astro-hw via file:...

When I use import { Button } from '@acme/components/button.vue' it does not render anything
but when I do import { Button } from '../../node_modules@acme/components/button.vue' it does work

Sorry I don't have reproduction repository mainly because astro cannot be declared as dependency expect via file:...
(So basically I need 3 projects astro-hw , components and the astro one)

Possible race condition during file output

Seems that using the main branch's astro.mjs for building a simple project (simply create a simple index.astro and use a Counter.tsx React component under <Counter:idle />) could potentially trigger a race condition of output files.

Occasionally (running a few times. If the bundle is present, delete the whole dist folder and try again. I usually hit this bug in 1 out of 4 attempts) the react-dom bundle could not be found in the dist/ folder, rendering the build broken. However, rerunning the build command could have a very high chance of writing the bundle back to dist/. It is unclear what is going on, but very likely a race condition is happening that does not wait for the file to be fully written before the command exits.

CSS optimisation is reordering styles in unpredicted way

Hi!

I'm using 0.0.12 successfully but migrating to 0.10.0 introduced an issue only at build.
I think this is related to css bundling of the new release.

I'm using global reset css and utility classes that I load on all the pages.
I just do

<link href="/css/reset.css" rel="stylesheet"/>
<link href="/css/global.css" rel="stylesheet"/>

in my base layout head.

In astro build of the latest version, the bundling of the styles creates a single chunck with all reset.css, global.css and scoped css of astro components. (great!)

But, the reset.css and global.css are at the end of the new file.

It's different in dev mode where the scoped css astro component are loaded at the end of the head so after reset.css and global.css.

It creates different behaviour from dev and build, and I don't know how to implement css reset because I don't see any other way to say to astro: "hey! please load this css before anything else".

Thanks

Default example has horizontal Scroll

🐛 BUG: Relative paths in `.astro` files to resources could produce unexpected results

CodeSandbox link to referenced code sample: https://codesandbox.io/s/boring-bush-l53wc?file=/astro/pages/index.astro (it won't work by itself since Astro is not published yet)

Warning: this is more of a feature abuse/discussion of the current code capability by me instead of a real practical bug report, but it does have some interesting implication when developers use Astro in unintended ways.

Suppose we have an Astro file astro/pages/index.astro and suppose there is a file astro/pages/social.png (that we want to reference but not placed in public/ folder (this might not be the intended usage, but some developers might be tempted to do so when migrating):

<html>
  <body>
    <img src="./social.png" />
  </body>
</html>

When running astro build, ./social.png won't be resolved. The reason is obvious when reading the code: ./social.png becomes /social.png in runtime.load(...) since it goes through a URL processing phase:

https://github.com/snowpackjs/astro/blob/077fceabcb4a505106ffa832ee252d786bb1e872/src/runtime.ts#L47-L49

And that for Snowpack, path in config.public is mounted as /, so the resolution would fail (as there is nothing in the public/ folder). Theoretically this should be considered as a misuse by the developer, but nicer error reporting might be helpful, since currently the error would look like:

[build] NotFoundError: Not Found (/social.png)

Suppose the developer (if s/he is determined enough to not use pubilc/) tries to read the source code (or just inspect the output _site folder) and figured out that astroRoot (default to ./astro) is in fact mounted on Snowpack as ./_astro:

https://github.com/snowpackjs/astro/blob/f28cebcf61ae6206383dabc957366b3ab6edb6e1/src/runtime.ts#L249-L252

And therefore in Snowpack the value to key mapping "/_astro/pages/social.png" => "[...]/astro/pages/social.png" exists, s/he might be tempted to do such:

<html>
  <body>
    <img src="./_astro/pages/social.png" />
  </body>
</html>

Another funny behavior would emerge instead: the runtime.load(...) on this resource would work, but the following step would write the static file (writeResult(...)) to ./_astro/pages/social.png instead of ./_site/_astro/pages/social.png, thus making the eventually emitted files still broken (as the src on img is not touched). This behavior is due to

https://github.com/snowpackjs/astro/blob/f28cebcf61ae6206383dabc957366b3ab6edb6e1/src/build.ts#L196

which, when supplied ./_astro/pages/social.png, produces ../_astro/pages/social.png, and thus steps out of _site and write static files outside.

I don't really have a clear idea about what should be done here, but these 2 cases are potential mistakes that a developer could make, and current error reporting seems do not make things clear when they happen.

`:visible` components throw error

Reproduction

Modify /examples/kitchen-sink/astro/pages/index.astro to add :visible to any component.

When the page loads, the following error will occur:

Uncaught TypeError: document.querySelector(...).item is not a function

Issue

Here's the generated JS that's breaking:

Array.from(document.querySelector('[data-astro-id="2245226923414180"]').item(0).children).forEach(child => o.observe(child))

It looks like #72 changed how the IntersectionObserver gets set up to support having multiple components:

https://github.com/snowpackjs/astro/blob/188541260acad5ccd6699f0a21d6da600860e74c/src/frontend/render/renderer.ts#L58

It's now expecting root to be a call to querySelectorAll instead of querySelector, but it's still querySelector:

https://github.com/snowpackjs/astro/blob/188541260acad5ccd6699f0a21d6da600860e74c/src/frontend/render/renderer.ts#L23

As far as I can tell, all of the renderers are expecting root to be a call to querySelector, and the IntersectionObserver bit is the only part of the generated code that expects querySelectorAll. It seems like reverting the change to this line would fix :visible, but as I don't really know the context of the previous change, I don't know what else that might break.

💡 RFC: [config] Expose adress in addition to port for dev server

Hi Team,

I would like configure something else than 127.0.0.1.
Port is already configurable but not the listening address.

Thanks

prettier support for `.astro` files

it would be great if prettier could format .astro files.

you can get something very basic working in vscode with:

// .vscode/settings.json
{
  "prettier.documentSelectors": ["**/*.astro"]
}

// prettier.config.cjs
module.exports = {
  overrides: [
    {
      files: "*.astro",
      options: {
        parser: "html",
      },
    },
  ],
};

but this will only format the html content; it doesn't know how to handle the frontmatter or templated JS.

npm build on .svelte files erroring on paths

npm build in kitchen sink gives relative path errors

(node:587165) UnhandledPromiseRejectionWarning: Error: Could not load /_astro/components/SvelteCounter.svelte: ENOENT: no such file or directory, open '/_astro/components/SvelteCounter.svelte'

...
opened pr #113 to test that kitchen-sink builds in workflow

Running projects outside examples folder fail due to `_astro_internal` not being mounted

Following the README setup:

# currently "hidden" during private beta
npm init astro@shhhhh ./my-astro-project

# then... cd => install => start
cd ./my-astro-project
npm install
npm start

And adding, as an example, a svelte file like Button.svelte inside components folder makes both npm run startandnpm run build` commands fail with error:

Error: Not Found (/_astro_internal/render/svelte.js)

Doing preliminary investigation it looks like both commands use snowpack dev server to create a list of files (fileToUrlMapping) to be served. ATM these commands fail because node_modules is being added to the ignore list and therefore they (node_modules/astro/lib/frontend/render and node_modules/astro/lib/frontend/runtime) will be omitted from the file list and not being mounted (https://github.com/snowpackjs/snowpack/blob/main/snowpack/src/commands/dev.ts#L303-L314).

Having a lot at the snowpack project I've noticed this PR (FredKSchott/snowpack#3134) that would allow mounting node_modules directory but we might be missing an update to thestartServer function.

Feature request: _don't_ run `npm install` when creating a new project

As a pnpm user, it's annoying to have to have to wait way longer before getting into a project because of an initial install step that I'm going to undo myself anyways, same goes for the numerous Yarn users. I also don't think it's a huge ask for npm users to run their own install, either.

I like Vite's approach: generates the files, then tells the user to run npm/yarn install when it's done.

withastro / astro Goto Github PK

astro's People

Contributors

Stargazers

Watchers

Forkers

astro's Issues

Component approach to layouts

Markdown pages compiled to layout usage

HMX pages that don't use layouts

Problem(s) to solve for

Proposal

HMX Styles

Default behavior

Sass support

Inlining

Importing

JS Styles

CSS Modules

SSR components

Dynamic components

Summary

Proposal

Risks

✋ I wanna help

Info

Versions

Some pieces that need discussion / fleshing out:

Main gist

Syntax

Other notes

Info

Versions

Reproduction

Issue

Recommend Projects

Recommend Topics

Recommend Org