unable to build or serve with Greenwood when developing a theme pack
#689
Comments
thescientist13
added
P0
thescientist13
changed the title
build or serve a theme pack _for development_build or serve with Greenwood when developing a theme pack
|
OMG, I just realized we might be able to completely bypass this by just using having all plugin authors just use relative paths in their templates!? 🤦 So instead of hardcoding node_modules path like this like we are documenting now <!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="/node_modules/greenwood-starter-presentation/dist/styles/theme.css"></link>
<link rel="stylesheet" href="/node_modules/greenwood-starter-presentation/dist/styles/main.css"></link>
</head>
<body>
<content-outlet></content-outlet>
</body>
</html>to just this! <!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="../styles/theme.css"></link>
<link rel="stylesheet" href="../styles/main.css"></link>
</head>
<body>
<content-outlet></content-outlet>
</body>
</html>that should work anywhere as long as you just copy the directory structure to node modules. This means that we should then be able to completely remove the need for all of the issues here - #682
🤞 |
|
ANOTHER UPDATE: Testing this locally in my starter presentation this also solves the Just need to test publishing and so it could just be that is just something that we might need to update in the docs / specs, and may not require another release, per se. 💪 |
|
So unfortunately, while relative paths work great for the plugin author's local development context When consuming a theme pack template from a consuming project and wanting to do something like this <link rel="stylesheet" href="../styles/theme.css"></link>The URL coming into the Koa server will then look like this, which will then 404 (since right now we only really check the user workspace for these kinds of relative paths) ORIGINAL URL /<pages-directory/styles/theme.cssSo if we just recommend plugin authors be explicit about node modules location (like the current recommendation) <link rel="stylesheet" href="/node_modules/greenwood-starter-presentation/dist/styles/theme.css"></link>then at least everything works in the user's app, both with So I think we'll have to "go back" to the bit more cumbersome theme pack author workflow, but there will also need to be a rollup work around we'll need to add for local development as well, so Rollup knows where to look for things. I think this would be the same solution we use for GraphQL. And I will definitely write some more tests since I totally missed properly testing the duality of theme packs. (developing for and consuming) 🤦 Also, I see we should probably warn if the template location doesn't exist, too. |
Type of Change
Summary
Bit of a fail on my end, but although I added test cases for developing and building a Greenwood project when consuming a Theme Pack, I didn't actually properly test the perspective of a user a publishing / producing a theme pack with Greenwood. And so although parts of the Theme Pack guide still apply for development at least, trying to run
greenwood build | servefails because (naturally) Rollup is going to find the paths the paths in HTML to node modules in the developer's repository.FWIW
greenwood developworks just fine, and I still need to test with publishing, so will see if there is a need for any updates on that as well, and add them here.For now, will mark
v0.15.0release as a pre-release for now.Details
So in this reference repo, when I run
greenwood buildon that branch, Rollup is unhappyBasically, just like we suggest creating a resource for development, we're going to need to do something similar in our rollup code to see if any user plugins can resolve it? Ideally would like to find a way to have this only be a local development workaround. Maybe an agreed upon rollup plugin that users can drop into their development environment?
Maybe some future thoughts for #682
Should also add some tests to cover this persona in our test cases; someone building a Greenwood plugin_
The text was updated successfully, but these errors were encountered: