I'm writing a nuxt module following this guide.
Now I would like my module to add a proxy rule to the host application. Its a lot of guesswork and nothing has done the trick so far. I tried
nuxt.options.proxy.options.push(
{
target: 'https://target-url.com',
changeOrigin: true,
pathFilter: ['path/to/match']
}
)
}
but my IDE complains that proxy is not a known property of NuxtOptions. I did shorten the above code for the sake of this post. In my code I also made sure the respective objects exist before assigning something to them.
next best guess (based on the example for adding a css library) was to do the same thing, but on the runtimeConfig like so:
nuxt.options.runtimeConfig.proxy.options.push(...)
no complaints by the IDE anymore (duh, the runtimeConfig object is of type any) but no sign of the proxy actually working.
I looked at stylelint's docs and only saw a way to disable stylelint for running on for specific files/directories but what I really want is a way to disable specific rules) for specific files/directories. Is there a way to achieve that? I don't want to use stylelint-disable within the files.
In the future, you'll be able to use the overrides configuration property. In the meantime, you can work around this missing feature by using the extend configuration property and by running stylelint twice.
Create a second config that extends the more limited main config and turns on additional rules:
.extended-stylelintrc.json:
{
extends: "./.stylelintrc.json",
rules: {
"unit-whitelist": ["px"]
}
};
Or you can create a second config that extends a full main config and turns off rules:
.limited-stylelintrc.json:
{
extends: "./.stylelintrc.json",
rules: {
"property-no-unknown": null
}
};
It will require two npm tasks to run it, though:
stylelint "**/*.css"
stylelint "special/**/*.css" --config .extended-stylelintrc.js
Or it can be combined into one:
stylelint "**/*.css" && stylelint "special/**/*.css" --config .extended-stylelintrc.js
In that case, you can not use the ignoreFiles option
or .stylelintignore?
ignoreFiles
You can provide a glob or array of globs to ignore specific files.
For example, you can ignore all JavaScript files:
{
"ignoreFiles": ["**/*.js"]
}
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.
I see that the ability to specify JSHint options on a per directory basis was added here.
However it is not clear to me how you actually take advantage of this. What do I do to set JSH options in a single directory, so that the options differ from other directories?
It appears that the change in question actually allows you to specify overriding options on a per-file basis. You can add an overrides property to your config, the value of which should be an object. The keys of this object are treated as regular expressions against which file names are tested. If the name of the file being analysed matches an overrides regex then the options specified for that override will apply to that file:
There's an example of this in the cli.js test file diff in the commit you linked to:
{
"asi": true,
"overrides": {
"bar.js$": {
"asi": false
}
}
}
In that example there is a single override which will apply to any files that match the bar.js$ regular expression (which looks like a bit of an oversight, since the . will match any character and presumably was intended to only match a literal . character).
Having said all that, it doesn't look like the overrides property is going to help you. I think what you actually want is a new .jshintrc file in the directory in question. JSHint looks for that file starting in the directory of the file being analysed and moves up the directory tree until it finds one. Whichever it finds first is the one that gets used. From the docs:
In case of .jshintrc, JSHint will start looking for this file in the same directory as the file that's being linted. If not found, it will move one level up the directory tree all the way up to the filesystem root.
A common use case for this is to have separate JSHint configurations for your application code and your test code. This allows you to define the different environments and globals separately.
I'm using grunt-init to build a template for a site structure I repeat regularly.
The template.js file uses the init.copyAndProcess function to customize most of files but a few of them get corrupted by the file processing (some fonts and image files) and I want to include those files in the 'noProcess' option. If these files all existed in the same directory, I could use the noProcess option as mentioned in the documentation [ See: http://gruntjs.com/project-scaffolding#copying-files ] and pass in a string like and it works:
var files = init.filesToCopy(props);
init.copyAndProcess(files, props, {noProcess: 'app/fonts/**'} );
Unfortunately the files that I need to have no processing performed on are not all in the same directory and I'd like to be able to pass in an array of them, something like the following block of code, but this does not work.
var files = init.filesToCopy(props);
init.copyAndProcess(files, props, {noProcess: ['app/fonts/**', 'app/images/*.png', 'app/images/*.jpg']} );
Any thoughts on how I can have multiple targets for the 'noProcess' option?
As soon as I posted the question, I realized that my proposed code did work. I simply had an invalid path when I'd renamed my 'app' directory to 'dev'.