CSS files in library modules are not autoprefixed #11480
Comments
The |
Yes, when I copy the file to the root then the library project is also autoprefixed. Well, I see how this will probably be the solution for this issue but unfortunately it is not really a good solution for me. As I tried to explain in the long text above in my opinion the auto-prefixing is the responsibility of the app build and should not be done in the library build. Because when I now compile the library with -ms- prefixes then an other application which also needs -webkit- prefixes can't use this library. So it would be nicer if the libraries don't have to auto-prefix anything (as they usually also don't enforce the usage of any polyfills) and the app build (Which knows which browser must be supported and is also already responsible for the polyfill selection) instead also autoprefixes component styles from external libraries. |
So this is not bug. Unfortunately, prefixing a component which is in a library from the application is not something that is possible at the moment and there are too many disadvantages of not shipping inlined css. Some of these are;
I am not quite sure, that it is actually possible to inline css in a component after it was compiled at library level. What I suggest is that as a library developer you should say that you will support a certain amount of browsers and you only prefix for those. This is even what big components libraries such as Angular Material & Ionic do. |
Guess I have to live with that. So the only remaining minor problem is that |
that |
So I have to place the application browserslist file in So looks like currently it is only possible to define a default browserslist in the root and an application-specific browserslist in I think it would be more intuitive if a library-specific file could be placed in |
Sorry for the back and forth but, I am on my mobile at the moment and it’s
hard to see the code.
I can now confirm that indeed that a bug as there is a typo error. I’ll try
to fix it later on today or over the weekend.
…On Fri, 06 Jul 2018 at 18:50, Klaus Reimer ***@***.***> wrote:
So I have to place the application browserslist file in src and the
library browserslist file in the root directory? This feels kinda wrong. I
tried placing the file in projects, projects/demolib and
projects/demolib/src, it doesn't work. It only works when the file is in
the root directory.
So looks like currently it is only possible to define a default
browserslist in the root and an application-specific browserslist in src.
But it is not possible to define a library-specific browserslist file. The
library always uses the default. So it is also not possible to define two
libraries with different browserslist files.
I think it would be more intuitive if a library-specific file could be
placed in projects/demolib or projects/demolib/src.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11480 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQv-WgLVVk6NmqiULcpENL8lVnwK9O27ks5uD5VegaJpZM4VFdwJ>
.
|
`filePath` is not a valid option. The correct one is `path` https://www.npmjs.com/package/browserslist#js-api Closes: angular/angular-cli#11480 (comment)
`filePath` is not a valid option. The correct one is `path` https://www.npmjs.com/package/browserslist#js-api Closes: angular/angular-cli#11480
`filePath` is not a valid option. The correct one is `path` https://www.npmjs.com/package/browserslist#js-api Closes: angular/angular-cli#11480
`filePath` is not a valid option. The correct one is `path` https://www.npmjs.com/package/browserslist#js-api Closes: angular/angular-cli#11480
`filePath` is not a valid option. The correct one is `path` https://www.npmjs.com/package/browserslist#js-api Closes: angular/angular-cli#11480
Fixed in |
I can confirm that inline CSS (in apps or libraries) is never preprocessed by the application build system. Libraries, when built, always inline their CSS, so that ends up being unprocessable as well. |
I'm still experiencing this issue. I placed the 'browserslist' file in parallel with the main 'package.json' file. There doesn't seem to be an What is the proper way to apply autoprefixer to a library build? |
The fix was applied in version The browserlist should be located parallel to the package.json of the library. Unfortunately, if there is bug it is not something that we at Angular-CLI can fix, and thus it is suggested to open an issue with ng-package, if the problem persists. Thanks. |
@alan-agius4 Thanks for the response! I'm happy to open an issue there, but I don't understand your comment. The issue you have linked doesn't seem to be relevant and looking at npm there doesn't seem to be any |
Apologies I updated the link. That said you are right, it looks like for some reasons the 3.0.4 is only mentioned in the changelog and was not published to the npm registry. But there should be the fix for that issue, so maybe you can also see how it’s being implemented from a consumer level |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug Report or Feature Request (mark with an
x
)Area
Versions
Repro steps
Create a new demo app and a library project:
Add some old browsers to src/browserslist:
Add the following CSS to src/app/app.component.css:
Change projects/demolib/src/lib/demolib.component.ts to use an external CSS file:
Create projects/demolib/src/lib/demolib.component.css with the following content:
Include the demolib module in the application by changing src/app/app.module.ts:
Compile the library project and the app:
The log given by the failure
Open the created dist/demo/main.js file and notice that the app CSS is prefixed but the library project CSS is not:
Desired functionality
I would expect that all CSS in the project is autoprefixed according to the browserslist configuration.
Mention any other details that might be useful
Looks like the external CSS in the library project is embedded into the component by the compiler and it looks like the autoprefixer does only work with external CSS. So maybe this can be fixed by keeping the CSS external in the library and let the application build handle it? Or maybe the autoprefixer can be changed to also process embedded CSS? Then it would be possible to use embedded CSS in the app project, too, which is currently not autoprefixed.
However this issue is fixed it would be nice if it could be fixed in the application build (by autoprefixing the external CSS) and not in the library build (by running the autoprefixer there as well). Because in my opinion the application is responsible for deciding which browsers to support, not the library. The library can't know in which browsers it is used later. As long as the library is in the same project as the app this doesn't really matter but imagine you create an independent Angular component library, publish it on NPM and some app uses it as an external dependency. Now the App wants to support old IE and needs to prefix the CSS provided by the component library. This could work if the library project still provides the external CSS files which the app build can autoprefix before embedding it into the app bundle. Or the library project can embed the CSS into JavaScript and add some info to the generated metadata.json so the app build knows where the CSS can be found to pass it through the autoprefixer before writing it into the app bundle.
The text was updated successfully, but these errors were encountered: