profile
viewpoint

lucydsl/liblucy 316

Core Lucy compiler

matthewp/analog-clock 5

A clock, analog style

matthewp/aremodulesready 4

https://aremodulesready.com/

canjs/can-deep-observable 2

Recursive observable type

matthewp/astro-lit-demo 2

Just a demo of the Lit renderer

canjs/can-stache-animate 1

Animations and How-Tos for Animating in Stache

lucydsl/lucy-vscode 1

VSCode plugin for Lucy language

matthewp/agate 1

Agate is a port of Enyo Onyx to Backbone views

issue commentwithastro/astro

๐Ÿ› BUG: Astro.resolve() full path URLs behave oddly, should be relative to root?

@brpaz which issue exactly? Afaik this shouldn't break anything.

FredKSchott

comment created time in 15 hours

issue commentwithastro/astro

๐Ÿ› BUG: getting `roots[0] is undefined` after browser reload when doing client-side hydration

So this comes down to a Vite bug. What happens is the inline scripts we create to render components get cached by Vite. Checking on what is the appropriate way to bust the cache on these. Should be fixable though.

imballinst

comment created time in 4 days

pull request commentwithastro/astro-compiler

Fix CSS comments

lgtm!

drwpow

comment created time in 4 days

issue commentwithastro/astro

๐Ÿ› BUG: getting `roots[0] is undefined` after browser reload when doing client-side hydration

So yeah, as you figured out using Date is the cause here. I think what is going on is that because the Date is changing the contents of the HTML is changing, which is what those ids are based on (it hashes the contents). Doesn't mean this should break, of course, still diagnosing.

imballinst

comment created time in 4 days

pull request commentwithastro/astro

[prototype] Free up build memory with SQLite

@matthewp might be correct that

I'm not, I checked the code and we parse the HTML as second time.

drwpow

comment created time in 4 days

issue commentwithastro/astro

๐Ÿ› BUG: Astro.resolve() full path URLs behave oddly, should be relative to root?

However, they do appear to load in the browser when requested via a <link> tag. This is confusing behavior: why do I get a 200 sometimes and a 404 other times?

My guess is that Vite is serving these differently depending on the accept header. I know that it does use that header to decide whether to serve JavaScript or CSS for css file paths. Not sure why the 404 in this case.

I wonder if the absolute URL support is something that we added as a workaround

No, it comes from Vite.

unfortunately createAstro() doesn't have access to the config root value

Yeah, that's why it works like this. Although we could probably pass this in via the compiler.

FredKSchott

comment created time in 4 days

pull request commentwithastro/astro

Support for unocss (and similar CSS plugins)

This is been reworked to no longer use fetch / listen on a port. The failing tests are due to a change that would be needed in unocss to not throw when it encounters CSS that doesn't have its placeholder value.

How this works now is to load the SSR module that exists for every module that is loaded during the rendering phase. This happens as a last fallback. The reason this uses ssrLoadModule and not transformRequest is that transformRequest gives you JavaScript and we want the raw value.

There is some downside to this approach. First, it relies on plugin ordering mutation. This plugin needs to be the second-to-last because vite has its own fallback plugin that throws when it can't find a module on the filesystem.

Note that this will not fix vite-imagetools as that's a related, but slightly different, issue.


Probably the long-term fix to this general problem is to produce an SSR build and then use that build to generate the pages. This would allow plugins to do their "normal" thing, which in the case of things like unocss and vite-imagetools is to produce an asset of their own. It would also mean no more multiple instances of plugins because we would not use viteServer.loadSsrModule at all.

matthewp

comment created time in 4 days

push eventwithastro/astro

Matthew Phillips

commit sha aed07432a20c6c1200f1d5c8c779471cba5a15a7

Move the new plugin over

view details

push time in 4 days

pull request commentwithastro/astro

[examples] move styles from public to src

lgtm

FredKSchott

comment created time in 4 days

push eventwithastro/astro

Matthew Phillips

commit sha 4194e8b8f83e331cf46473bd804429ef509b4958

Remove extra stuff

view details

push time in 4 days

push eventwithastro/astro

Matthew Phillips

commit sha 56a952fae0658bafcc11caf771f689388cd69f12

Use the SSRed contents

view details

push time in 4 days

issue commentantfu/unocss

Support in Astro

Yeah removing it does work. However I might be able to set ssr: true, so let me try that.

matthewp

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentwithastro/astro

Support for unocss (and similar CSS plugins)

+import { expect } from 'chai';+import cheerio from 'cheerio';+import { loadFixture } from './test-utils.js';++describe('unocss', () => {+  let fixture;++  before(async () => {+    fixture = await loadFixture({+      projectRoot: './fixtures/with-unocss/',+    });+    try {+      await fixture.build();+    } catch(err) {+      console.log('wha...', err);

hah, yes

matthewp

comment created time in 5 days

issue commentantfu/unocss

Support in Astro

I almost have a fix on our end. Since the CSS is loaded through SSR (the reason the plugin runs twice), it already exists and we can just request the /__uno.css file from Vite.

It fails currently because of this though: https://github.com/antfu/unocss/blob/7481fc3f9d5c61c0aea33a8fa31caf341a749ceb/packages/vite/src/modes/global/build.ts#L119-L120

I think this throw is possibly wrong; it assumes that if a project has CSS it must be unocss usage, but Astro allows mixing CSS techniques. If the user has client-side usage of uno it will pass; if its only used in .astro files this will throw.

I think this throw should be removed.

matthewp

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentwithastro/astro

Support for unocss (and similar CSS plugins)

 export function rollupPluginAstroBuildHTML(options: PluginOptions): VitePlugin {         });       }     },-  };+  }, {+    name: '@astro/rollup-plugin-build-load-fallback',+    enforce: 'post',

This is 'post' so it runs last. Only a fallback for pathnames.

matthewp

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentwithastro/astro

Support for unocss (and similar CSS plugins)

 export function rollupPluginAstroBuildHTML(options: PluginOptions): VitePlugin {         });       }     },-  };+  }, {+    name: '@astro/rollup-plugin-build-load-fallback',+    enforce: 'post',+    resolveId(id) {+      // If we got here, nothing picked up this module, so let's try+      // and grab it from the viteServer used for SSR loading.+      if(id[0] === '/') {+        return id;+      }+      return null;+    },+    async load(id) {+      const init: RequestInit = {+        headers: {+          accept: mime.getType(id)+        }+      };++      const res = await fetch(id, init);

This is where the fix is. Since there is no client-side usage of uno.css, only SSR, the CSS for this module is in the viteServer. So we need to fetch() against it to get the result.

matthewp

comment created time in 5 days

Pull request review commentwithastro/astro

Support for unocss (and similar CSS plugins)

 class AstroBuilder {     );     this.viteConfig = viteConfig;     const viteServer = await vite.createServer(viteConfig);+    // Listen to the server so that we can make fetch requests if needed.+    await viteServer.listen(this.port);     this.viteServer = viteServer;     debug(logging, 'build', timerMessage('Vite started', timer.viteStart));      timer.loadStart = performance.now();+    const fetch = createFetch(this.origin);

This is a localized fetch so you can do fetch('/path/to/file.css'), and can be passed to plugins that need it.

matthewp

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentwithastro/astro

Support for unocss (and similar CSS plugins)

 class AstroBuilder {         {           mode: this.mode,           server: {-            hmr: { overlay: false },-            middlewareMode: 'ssr',

This is needed so that we can cal createServer(). I didn't notice a difference without it.

matthewp

comment created time in 5 days

PullRequestReviewEvent

push eventwithastro/astro

Matthew Phillips

commit sha cf98c0f082107ba213ed08a68f5d1250c14f38db

Adds a changeset

view details

push time in 5 days

PR opened withastro/astro

Support for unocss (and similar CSS plugins)

Changes

  • Note that this is currently failing due to an issue in unocss itself (reaching out about that separately).
  • This creates a fallback plugin where we fetch from the SSR server that's used for rendering pages.

Testing

Test added

Docs

N/A

+363 -15

0 comment

8 changed files

pr created time in 5 days

create barnchwithastro/astro

branch : unocss

created branch time in 5 days

issue commentwithastro/astro

๐Ÿ› BUG: Windicss, UnoCss etc... doesn't properly work in astro

Thanks for filing the issue. We are collaborating with the uno.css maintainer on a solution. https://github.com/antfu/unocss/issues/105

Blinks44

comment created time in 5 days

issue commentwithastro/astro

๐Ÿ› BUG: Scoped component styling seems to be broken in Astro v0.21.2

Thanks for the reproduction. Obviously you are right, these should be scoped, so we'll have to dig into what is going on.

markteekman

comment created time in 5 days

more