Eleventy site skeleton - #1333
Conversation
| @@ -1,5 +1,5 @@ | |||
| { | |||
| "name": "webcomponents.org", | |||
| "name": "@webcomponents/internal-site", | |||
There was a problem hiding this comment.
Was this renamed because something is going to depend on it? If the package is private and nothing depends on it and it's in an org, there's no name-attack possible on it, right?
There was a problem hiding this comment.
There is probably no feasible attack unless we publish, yeah. However, I think it's just a good habit to get into for npm development, because in other scenarios there are attacks. I think we should simply never declare a package name that we don't own, or in a namespace that we don't own, as a rule.
| "format": "prettier \"./packages/*/src/**/*.ts\" --write" | ||
| }, | ||
| "dependencies": { | ||
| "@11ty/eleventy": "^1.0.2", |
There was a problem hiding this comment.
Why is 11ty installed here and not in packages/content?
There was a problem hiding this comment.
I kinda figured it didn't matter, since it all goes to the same place anyway, and these are private packages. But I guess for organization it's still a bit useful. Fixed in #1334
| */ | ||
|
|
||
| module.exports = (eleventyConfig) => { | ||
| eleventyConfig.addPassthroughCopy('site/assets'); |
There was a problem hiding this comment.
did we ever figure out a pattern to symlink in dev and copy in prod?
There was a problem hiding this comment.
Yep, we have that for lit.dev. In #1334 I've actually found an even simpler way to do it.
| @@ -0,0 +1,21 @@ | |||
| { | |||
| "compilerOptions": { | |||
| "target": "es2021", | |||
There was a problem hiding this comment.
Looking at compat tables, I think we can do 2022 now.
Sets up separate dev and prod eleventy builds for the new webcomponents.org. Both builds use esbuild. Running `npm run watch:dev` or `npm run watch:prod` from the top-level will give you live refresh versions of either build. The dev build is super fast because [1] it uses symlinks so that Eleventy doesn't need to rebuild when static assets or JS changes, and [2] it runs esbuild with no minification or bundling. There is a separate `check:types` command in the `client` package which runs TypeScript in `noEmit` mode. This runs in parallel when you use either of the top-level `watch:*` commands. So the experience is that the browser updates immediately, and a few moments later you also get any type errors. This design lets us use identical `<script>` tags in both dev and prod mode, which is nice. On lit.dev we needed to generate different script tags for each mode. Also addresses the post-merge comments from #1333
contentpackage with a "hello world" eleventy sitecomponentspackage with a basic elementdevcommandWill add a server in a followup, and then get auto-deploy working