Source maps and minification for dynamic CSS modules. #9998
Conversation
|
This is pretty awesome. |
When a CSS (or compiled-to-CSS) module is lazy (e.g., in `imports/` or `node_modules`) and not otherwise imported by another CSS module, Meteor automatically turns it into a JS module so that it can be handled by the `ImportScanner`, and imported dynamically by other JS modules. Until now, there were two problems with CSS handled in this way: it did not have proper source maps, and the CSS text was not minified in production. This commit introduces a special minification step for dynamic CSS, which must take place before we create the dynamic JS module. Waiting for the usual minification of CSS would be a mistake, since that happens long after the `ImportScanner` and `Linker` have already processed JavaScript modules. Modifying the contents of JS modules at that point would be impossible without recomputing source maps, etc. Since the JS module dynamically creates a `<style>` tag and appends it to the `<head>` of the document, the code of the JS module has no meaningful relationship to the lines of CSS text that are actually evaluated by the browser, so it would be a mistake to give the JS module the same source map as the original CSS resource. Instead, when there is a source map, we write it out as an asset that can be requested at runtime, and append a sourceMappingURL comment to the end of the CSS text referring to this asset URL. Note that this only happens in development, which makes sense because minification in production invalidates the source map, and we don't want to expose source code in production anyway.
benjamn
force-pushed
the
source-maps-and-minification-for-dynamic-css
branch
from
35077ad
to
6fb9be1
Compare
|
@benjamn Does release 1.7.1-beta.3 here contain the fix for this (the whole fast less compiling issue and the crashing error)? |
|
@benjamn just tried the 1.7.1-beta.3 . While it works with just one less file "main.less" added in client dir, if I add the standard semantic-ui folder under client dir with all the less files.. it crashes with the following error: /Users/macpc/.meteor/packages/static-html/.1.2.2.wp43cd.99etr++os+web.browser+web.cordova/plugin.compileStaticHtmlBatch.os/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:190 TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object. I revert back to meteor 1.7.0.1 and the error disappears, css works, back to slow LESS compiling however. |
|
Hi, great news. Works perfectly in dev and prod. What about auto-prefixing? Are we going to get that through a plugin or will it be built in? |
|
this is looking very interesting. Some input concerning web components: Due to the encapsulated nature of CSS in a web component, injecting anything into the Just generate a js file which includes some arbitrary string at the beginning and another one at the end which you can then import from your component. For example, my current solution for importing external css is this: import { html } from '../base';
export default html`
<style>
* {
color: red;
}
</style>
`;So I would need to prepend anything until the closing Right now I have a superclass which handles this, but I can't use real css files. Bonus question: how to make those work with barbatus:typescript or a native typescript compiler? EDIT: I realize this is not zero-config. Probably a job for a plugin... |
When a CSS (or compiled-to-CSS) module is lazy (e.g., in
imports/ornode_modules) and not otherwise imported by another CSS module, Meteor automatically turns it into a JS module so that it can be handled by theImportScanner, and imported dynamically by other JS modules.Until now, there were two problems with CSS handled in this way: it did not have proper source maps, and the CSS text was not minified in production.
This commit introduces a special minification step for dynamic CSS, which must take place before we create the dynamic JS module. Waiting for the usual minification of CSS would be a mistake, since that happens long after the
ImportScannerandLinkerhave already processed JavaScript modules. Modifying the contents of JS modules at that point would be impossible without recomputing source maps, etc.Since the JS module dynamically creates a
<style>tag and appends it to the<head>of the document, the code of the JS module has no meaningful relationship to the lines of CSS text that are actually evaluated by the browser, so it would be a mistake to give the JS module the same source map as the original CSS resource.Instead, when there is a source map, we write it out as an asset that can be requested at runtime, and append a sourceMappingURL comment to the end of the CSS text referring to this asset URL. Note that this only happens in development, which makes sense because minification in production invalidates the source map, and we don't want to expose source code in production anyway.