-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement/issue 434 expand script style link tag production bundling #472
Enhancement/issue 434 expand script style link tag production bundling #472
Conversation
Had some more time to play around with this and the CSS side of things in particular, and I think there may be some caveats to keep in mind with supporting these two use cases in particular. <script type="module">
import '@some/code';
</script>
<style>
div {
a {
color: blue; /* notice nested selectors */
}
}
</style> because none of this will get handled by Koa, since it won't trigger a network request, I think it might be counter intuitive to run Babel / PostCSS on this code in Rollup since this would not be something users would be experiencing during development (for instance, nested selectors would not work), and so I think this introduces conflicting outcomes between development and production, which I think would not be a good workflow to enable. That said, I think we can still apply basic optimizations like minification (terser / cssnano) for free on these that we could put into the The more I've been thinking about this, the more I don't think we should be calling PostCSS (or Babel) directly in rollup.config.js either, as I don't want to couple these tools, since there is more options than these tools for optimizing code and so makes a much better case for plugins to take up this task (e.g. That said, I could definitely see us supporting these use cases fairly easily still... <script type="module" src="@evergreen-wc/eve-container">
<script type="module" src="@package/dist/index.js">
<link rel="stylesheet" href="@bootstrap/bootstrap">
<link rel="stylesheet" href="@bootstrap/bootstrap/dist/bootstrap.css"> But I would like to merge #465 first for it's refactoring, and then wrap up #426 , since it would introduce even more refactoring. |
945e642
to
3dfd106
Compare
5793a23
to
ef24291
Compare
So in the case here, where we can potentially have different bundling / optimizations in We can certainly make it work such that plugin-resource-html can scan for inline |
#472) * remove duplicate html parsing lib and refactor script and link emit logic accordingly * refactor rollup script and link tag updates to new html parser * handling bundling of inline script tags * code cleanup * wip * fixed bug with the implementation * restore optimization * add specs for script style link tag usage * add test for inline script with node_modules * use Buffer instead of cyrpto * remove comment * fix bug with incorrect script tag updating in rollup * fix bug with incorrect script tag updating in rollup * clean up scratch files and assert number of output bundles * support node modules via link and script tags * add specs for node modules link and style use cases * naming refactor * docs * small refactor
#472) * remove duplicate html parsing lib and refactor script and link emit logic accordingly * refactor rollup script and link tag updates to new html parser * handling bundling of inline script tags * code cleanup * wip * fixed bug with the implementation * restore optimization * add specs for script style link tag usage * add test for inline script with node_modules * use Buffer instead of cyrpto * remove comment * fix bug with incorrect script tag updating in rollup * fix bug with incorrect script tag updating in rollup * clean up scratch files and assert number of output bundles * support node modules via link and script tags * add specs for node modules link and style use cases * naming refactor * docs * small refactor
Related Issue
resolves #434
I gotchu fam
Summary of Changes
<script>
tag usage will get properly bundled by Rollup and inlined back into the HTML<script>
tag matching bug - (also seen in https://github.com/ProjectEvergreen/greenwood/pull/475/files#diff)TODO
<script src="...">
in the same document... (looks like this is due to a bug I saw happening inhttps://github.com/Bug/issue 431 template <head> tags merge order #475/files#diff-57634df7e2b1ba3ea0031d8adc1e73230ca3c93bbecfdea7b44d00c7e100ec8b as well)Would like handle similar case for inline CSS, e.g.- can't do this easily, just yet. how to avoid Puppeteer added inline styles?Buffer
orcrypto
Nice To Have
Summary / Thoughts / Takeaways
So for where this stands as of now, the general (to be) documented recommendation will be to use a file based entry point for all your scripts and styles, for anything anything doing any "heavy lifting" as this will afford the most opportunity for full and consistent bundling and optimization (at this time).
The mean reason is that since inline
<script>
and<style>
don't initiate any fetch / network requests, the ability for the Greenwood server to intercept these and run tranforms and optimizatoin's is limited and so may lead to different outcomes betweenbuild
anddevelop
commands. This is something we could try and support, but I think can come at a later time. For now, we can at least do node_modules directly, which is pretty great.Here are some examples of what is / isn't supported.