Type of Change
Summary
After having laid out some of the basic features and explored some of their implementation details:
I think though now we can define a higher level design that accounts for and can balance these various technical needs:
- Building a static site from a users src/pages/ and src/templates directories
- Providing a flexible user "workspace" / directory strucutre, e.g. src/*
- components
- assets
- styles
- etc
- Orchestrating all that through the graphing / scaffolding phases, lockstepped to the webpack powered build phase
Solving this is important because webpack will only know of code that is specified through entry
config, which right now requires an additional build steps before we can run it through webpack.
If we could use that scaffolded code, but also still respect paths to the user's source code, then we would have a pretty nice pipeline! This means we can also just use webpack-dev-server for the entire development stack too (I think) without any additional file watching, which would be awesome. (Though this should be confirmed, like when new pages are created, will webpack rebuild?)
Details
For example, given a user who provides their own page-template, and wants to import
some global CSS
// user's src/templates/app-templates.js
import { html, LitElement } from 'lit-element';
import css from '../styles/global.css';
MDIMPORT
class PageTemplate extends LitElement {
render() {
return html`
<style>
${css}
</style
<div class='wrapper'>
<div class='page-template content'>
<entry></entry>
</div>
</div>
`;
}
}
customElements.define('page-template', PageTemplate);
The issue is when the generated page is put into the scratchDir
(./greenwood/), the import
paths are now "out" of context, so to speak.
ex.
import { html, LitElement } from 'lit-element';
import css from '../templates/theme.css'; // this file will now 404
import './hello.md';
class PageTemplate extends LitElement {
render() {
return html`
<style>
${css}
</style
<div class='wrapper'>
<div class='eve-hello content'>
<wc-md-hello></wc-md-hello>
</div>
</div>
`;
}
}
customElements.define('eve-hello', PageTemplate);
So at a high level, this RFC is hope hoping to solve:
- A simple "API" for users
- pages/
- templates/
- that's it!
- A flexible user workspace through
import
or @import
- components/
- assets/
- styles/
- whatever/!
- Leverage webpack through and through for development and production
- Provide a clear development path for the above referenced issues
Proposals
Here are a couple ideas I have:
Context Linking, aka "src"mapping
I'm hoping webpack can actually solve this entire problem in a simple way for us (I hope) by using the ContextReplacementPlugin
With this, we can tell webpack where to look when resolving paths so that Greendwood can dynamically look up and link to a user's entire project without needing to configure everything other than
Path Rewriting
Similar in spirit, this approach would literally rewrite paths in place. So given the example provided in the detail section, we could instead generate a page from a page template like this
import { html, LitElement } from 'lit-element';
import css from '/Users/path/to/project/repo/<dynamic>/global.css';
import '/Users/path/to/project/repo/src/pages/hello.md';
class PageTemplate extends LitElement {
render() {
return html`
<style>
${css}
</style
<div class='wrapper'>
<div class='eve-hello content'>
<wc-md-hello></wc-md-hello>
</div>
</div>
`;
}
}
customElements.define('eve-hello', PageTemplate);