In vue component it is possible to use keyPrefix of i18n in order to use a shorter path to the translated key.
So, for example if my lang file looks like that:
{"a":{"b":{"c":{"placeholder": "my placeholder"}}}}
and in my vue component, set i18nOptions like that:
export default {
i18nOptions: {
keyPrefix: 'a.b.c',
},
I am able to consume the key like that:
$t(`placeholder`)
it works great! the problem is that eslint won't allow that (#intlify/vue-i18n/no-missing-keys)
I didn't find any way to teach eslint to handle that correctly...
did anyone manage to do it?
WARNING in chunk AccessRights~Groups~Navigator [mini-css-extract-plugin]
Conflicting order between:
css ../node_modules/css-loader??ref--7-1!../node_modules/postcss-loader/lib!./components/Icon/_circle/Icon_circle.scss
css ../node_modules/css-loader??ref--7-1!../node_modules/postcss-loader/lib!./components/Counter/Counter.scss
css ../node_modules/css-loader??ref--7-1!../node_modules/postcss-loader/lib!./components/NavigatorToolbar/NavigatorToolbar.scss
what does this mean and how to fix it? Thank you in advance!
"assets-webpack-plugin": "3.9.5",
"autoprefixer": "9.1.0",
"css-loader": "1.0.0",
"file-loader": "1.1.11",
"image-webpack-loader": "4.3.1",
"mini-css-extract-plugin": "0.4.2",
"postcss-advanced-variables": "2.3.3",
"postcss-clearfix": "2.0.1",
"postcss-conditionals": "2.1.0",
"postcss-extend": "1.0.5",
"postcss-functions": "3.0.0",
"postcss-hexrgba": "1.0.1",
"postcss-import": "12.0.0",
"postcss-loader": "2.1.6",
"postcss-media-minmax": "3.0.0",
"postcss-nested": "3.0.0",
"postcss-sassy-mixins": "2.1.0",
"postcss-simple-vars": "4.1.0",
"postcss-size": "2.0.0",
"postcss-urlrewrite": "0.2.2",
"source-map-loader": "0.2.3",
"string-replace-loader": "2.1.1",
"style-loader": "0.22.0",
"url-loader": "1.0.1",
"webpack": "4.16.5",
"webpack-cli": "3.1.0",
"webpack-dev-server": "3.1.5",
It can easily become an annoying bug! I can see it being reported in every framework -- e.g. in issue #5372 in create-react-app, issue #250 in the mini-css-extract-plugin itself, etc.
I spent 6 hours debugging it (including putting console.log in the source code of mini-css-extract-plugin where it omits the Warning) and here are my findings.
What is this plugin?
The mini-css-extract-plugin of webpack is a CSS-bundler. It is there to gather CSS pieces and put them into .css chunks for you. Just like what the whole Webpack build is doing for .js files.
Why is it happening to me?
You are running into it because all of these conditions apply to you:
You have Vue SFC or CSS-in-JS, that results in your CSS content being in different files (which are called modules).
Your webpack configurations are set to do some sort of code-splitting optimizations, (e.g. via split-chunks-plugin) which puts your modules into chunks for lazy-loading in client-side (e.g. 1000 files, into 10 chunks, that are only downloaded by the user when the user needs them.) So, this plugin goes over how webpack has bundled your modules and tries to create its own CSS bundles out of them.
There is an "Order Conflict" in your imports!
What is "Order Conflict" now?
It's "order" + "conflict." Let's review them.
Part 1) Order
This plugin is trying to run a topological sorting algorithm (this part of the source code) to find out in which order it should put the CSS rules in its output bundles so that it doesn't cause any problem.
The problem is, unlike JavaScript that you clearly export your objects from a file/module (in no order, as they are named), in CSS it will just get appended (like an array of strings) and so the order of the imports can actually matter!
Let's say you have two modules:
// module a.js
<div>hi, I am A!</div>
// ... in CSS section of the same file:
div { color: red; }
// module b.js
<div>hi, I am B!</div>
// ... in CSS section of the same file:
div { color: blue; }
And then you have a page that includes both of them them.
// page S (for Straight)
import a from "a.js"
import b from "b.js"
So far, so good! The CSS output can be
div { color: red; }
div { color: blue; }
which means all the <div>s should have blue font color.
However, if instead of that page S, we had a page had was importing them in reverse order, it would be:
// page R (for Reverse)
import b from "b.js"
import a from "a.js"
and the output would be equal to
div { color: blue; }
div { color: red; }
which means all the <div>s should have red font color.
This is why the order of imports matters.
Part 2) Conflict
Now, what should be the output CSS if you have both page S and page R?
Note that, unlike this silly example of applying a wild rule on all <div> elements, you might actually have some sort of scoped CSS or a CSS naming convention like BEM in place that would prevent such thing to become an issue. But, this plugin doesn't go over actually parsing and understanding the content of the CSS. It just complains that "Hey dude! I don't know whether a should come before b, or b should come before a!"
Solutions
You basically have two solutions, just like any other problem! Either solve it or kill the problem it.
Solution 1: Fix it
The error message is very hard to read and sometimes it doesn't even output the proper details of modules. (for me it's like , , , , , , as for some reason my ChunkGroups don't have a .name property; so zero information.) And it can be extremely messy if you have more than ~20 files.
Anyways, if you have got time this approach is the best you can try.
Notes:
You can also import PageS in PageR (or the other way around, whatever) to explicitly tell the plugin to pick this order and stop nagging! It might be easier than going over all the places that include one or another and move the lines up and down.
IMPORTANT NOTE 1: IF YOU THINK SORTING YOUR IMPORT LINES ALPHABETICALLY CAN HELP, SEE THIS EXAMPLE and THIS COMMENT (that even a Visual Code plugin cannot help)!
IMPORTANT NOTE 2: The Order Conflict is NOT NECESSARILY IN THE SAME FILE. It can be anywhere among the ancestors of the two or more files! So, can be a huge pain to find out.
IMPORTANT NOTE 3: IT'S NOT GOING TO BE FUTURE-PROOF! So, even if you move a few import lines up and down, tomorrow it might happen to another developer in your team.
So, TL;DR, if you found yourself spending more than two hours on this, try solution #2 below.
Solution 2: Kill it
If it's not actually causing a problem in production and your final output, you can suppress this error via passing an ignoreOrder flag to the options object of the plugin in your Webpack config.
Notes:
If you are using a third-party build-wrapper on top of WebPack (like Quasar's that I am using), you can use webpack chain modify arguments technique to feed this flag into the existing configuration.
It's a good last resort! Good luck. :)
CSS cares for rule order.
Q: What does the warning mean?
A: There are some order conflicts while packaging your CSS modules.
Q: What is the cause?
A: The plugin (mini-css-extract-plugin) tries to generate a CSS file but your codebase has multiple possible orderings for your modules. From the warning you showed, it seems you have used Icon before Counter in one location and Counter before Icon in another location. The plugin needs to generate a single CSS file from these and can't decide which module's CSS should be placed first. CSS cares for rule order so this can lead to issue when CSS changes without reason.
So not defining a clear order can lead to fragile builds, that's why it displays a warning here.
Q: How to fix?
A: Sort your imports to create a consistent order. If you cannot sort for some reason, for example, you have libraries in your project beyond your control or when the order of these styles doesn't matter, you can ignore the warning by making changes as suggested in other answers.
mini-css-extract-plugin version 0.8.0 included a new option ignoreOrder. You can check https://github.com/webpack-contrib/mini-css-extract-plugin#remove-order-warnings
new MiniCssExtractPlugin({
ignoreOrder: true,
}),
Please see issue reported on Github.
const webpackConfig = {
stats: {
// warn => /Conflicting order between:/gm.test(warn)
warningsFilter: warn => warn.indexOf('Conflicting order between:') > -1 // if true will ignore
}
}
There is now an NPM package named #webkrafters/ordercss which tackles this issue at the root.
Full disclosure: I initially created it to solve this very problem in one of my apps but decided to expand it and share it with everyone.
If this package helps anyone, please share it with others.
Thanks and good luck!
NB: setting MiniCssExtractPlugin ignoreOrder property would suppress the warnings but may not resolve the underlying issues especially for those using modular css. This could result in unpredictability of the rendered view.
For a new project I am bound to keep things webpack-only, and thus need to find a way to efficiently compile our stylesheets. Basically in a very gulh-ish way:
gather all less-files including glob-patterns like src/**/*.less (css order may be arbitrary)
also allow import of css files like, say ../node_modules/vendor/**/*.css or 3rdparty/master.less
(If I have to setup a bogus.js entry point for that, fine...)
And with all of that, a typical gulp workflow:
transpile less to css
merge (concat) less and css
have cssnano do its optimization job, with specific css nano options like e.g. orderedValues: false, normalizeWhitespace: true ...
write styles.css as final output
And of course:
have source-maps survive that chain for a styles.css.map
efficient watching and the usual lazy/incremental compilation (as gulp and webpack have it)
Something I do not need is css modules (css imported into node modules for 'scoped' use, coming out as hash-scoped selectors...)
How can a 'typical' less|css-processing toolchain be done in Webpack?
This SO question has my first attempt where I got stuck in config hell right in the middle after combining...
considerations so far (helpful or not)
I know, to webpack, any ressource including css or even font and images is a "module"... Rather than merging my css 'modules' with with actual js (only to later painstakingly separate them again later again), it might be wiser, to have an entry point cssstub.js in parallel – also known as multi-compiler mode.
But that's really, where my wisdom ends... doing a sequence of $things on a set of files in webpack seems really hard (unless it's a connected javascript module graph). I did find something on globbing, but that's not enough (merge css, cssnano,...) and mostly I simply can't glue the pieces together...
I have used gulp to build less and create corresponding maps like below:
First step compiles less and generated css in tmp folder
gulp.task('compile-less', function () {
gulp.src('./*.less') // path to your file
.pipe(less().on('error', function(err) {
console.log(err);
}))
.pipe(gulp.dest('./tmp/'));
});
Second step minifies generated css and create map files
gulp.task('build-css', ['clean'], function() {
return gulp.src('./tmp/**/*.css')
.pipe(sourcemaps.init())
.pipe(cachebust.resources())
.pipe(sourcemaps.write('./maps'))
.pipe(gulp.dest('./compiled/css'));
});
If you want you can add additional step to conact generated css.
You know, I spend more time just trying to get things set up to work with Angular than I do actually developing with Angular. There must be an easier way... :(
Currently, I am using the aspnetcore-spa template, creating a project with the command "dotnet new angular" - this is version 1.0.3, which adds Angular 4.1.2 to the npm dependencies. This works great to get a project running quickly. But now I want to add PrimeNG to take advantage of their form controls. I have been struggling with this all day, and would love it if anyone could provide some assistance.
Here is what I have done in my current effort (the latest of many, starting fresh each time):
1) Added to the package.json file: "primeng": "4.1.0-rc.2"
2) Added 'primeng/primeng' to the webpack.config.vendor.js file's vendor collection.
3) Added the following to my test module (which is in turn referenced in app.module.shared.ts so I can route to it via my RouterModule):
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
And in the html for the module, in an attempt to use the file uploader control, I have (from their site - https://www.primefaces.org/primeng/#/fileupload):
<p-fileUpload name="myfile[]" url="./upload.php"></p-fileUpload>
4) ran "webpack --config webpack.config.vendor.js" from a command prompt at the root of the project folder, which completed with no errors.
Then I hit F5 to run the project, and I got this error:
Exception: Call to Node module failed with error: Error: Template parse errors:
'p-fileUpload' is not a known element:
1. If 'p-fileUpload' is an Angular component, then verify that it is part of this module.
2. If 'p-fileUpload' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '#NgModule.schemas' of this component to suppress this message. (" type="button" (click)="onclick()" class="ui-button-info" label="Click Me">Click Me</button>-->
So, in an effort to comply, I added a reference to the ngprime module to the app.module.shared.ts file, like this (I don't really know how I should reference the module...):
import { FileUploadModule } from 'primeng/primeng';
But got the same exact error.
What am I missing???
Any help would be most appreciated.
I finally have this working, using the asp-prerender-module to get server-side rendering, and not having to rely on the asp-ng2-prerender-module (see my last comment). The trick, I found, was to reference the FileUploaderModule in the app.module.shared.ts file like this:
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
rather than like this:
import { FileUploadModule } from 'primeng/primeng';
The reason this matters is that the latter method of referencing will load all other components as well (see explanation here: https://www.primefaces.org/primeng/#/setup), and SOME of the PrimeNG components can not be rendered on the server due to DOM-related references (things like "window", which do not exist on the server). See the discussion here for more on this: https://github.com/primefaces/primeng/issues/1341
This change, combined with the other steps listed in my answer and, of course, actually referencing the directive in app.module (thank you #pankaj !) made everything work correctly at last. Only took me about 7 hours to figure it out. :(
Some modules just seem to be invisible to Flow. For example I have react-native-overlay installed via npm into my node_modules directory but I get a whole bunch of errors like this from Flow:
[js/components/DatePickerOverlay.js:18
18: let Overlay = require('react-native-overlay');
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ react-native-overlay. Required module not found
This module doesn't have types so it would be fine if I could just get Flow to ignore it entirely.
Here's my .flowconfig (based on React Native's one):
https://gist.github.com/almost/20c6caf6d18d0e5c689f
As you can see I'm on flow 0.20.1 and I have module.system=haste (as required by React Native)
I tried adding a //$FlowIgnore comment to the import lines but then Flow complains about an unneeded ignore comment! I also tried creating a react-native-flow.js.flow file with a dummy export which seemed to work at first but then after a flow restart stopped working.
Any ideas for how to either help Flow find this module or make it ignore the import line completely?
Looks like you're ignoring it here: https://gist.github.com/almost/20c6caf6d18d0e5c689f#file-flowconfig-L42-L50
If you don't mind manually typing it up, add a react-native-overlay.js to your interfaces and type up a couple signatures.
This is happening because the library doesn't exist in flow-typed.
A simple fix could be creating the following entry in the .flowconfig file:
[ignore]
<PROJECT_ROOT>/libdefs.js
[libs]
./libdefs.js
If using flowtype < 0.60.0 add in libdefs.js
// #flow
declare module "react-native-overlay" {
declare var exports: any;
}
Or if using flowtype > 0.60.0
declare module 'react-native-overlay' {
declare module.exports: any;
}
Note: any is an unsafe type so you can always take advantage of improve the definition of the library
Hope that helps,