Sublime ignores eslint settings - global-variables

I am using the standard linter via the SublimeLinter-contrib-eslint package and it seems to ignore these entries in both SublimeLinter.sublime-settings and ~/.eslintrc:
{
"globals": {
"describe": true,
"it": true,
"expect": true,
"angular": true
}
}
I am still getting these globals as undefined.
Any other way to declare them?

I'm not sure about SublimeLInter.sublime-settings, but ~/.eslintc file will only be used if no other eslint config files are found. Since you are using standard, I assume that you have another .eslintrc file somewhere. You will have to add those globals there.

Related

Sass - via Webpack Mix - ignores options

I am using Webpack Mix and I am attempting to set some options - includePaths. But it appears that sass &/or webpack mix is ignoring all these options. I know this because in my sass I have #import url('icons/styles.css'); which should resolve to #import url('dist/assets/icons/styles.css'); but it fails to compile with an error about not being able to locate the file.
So I then tried to set my webpack mix options to processCssUrls: false so it will just ignore my url() altogether and the same error occurs. Which leads me to believe that webpack mix is igoring my options?
Any advice on how to get sass to either resolve my url paths or just ignore them?
let mix = require('laravel-mix');
mix.setPublicPath('dist')
.js('src/app.js', 'scripts/')
.extract([
'jquery',
'axios',
'babel-polyfill',
'lodash',
'tether',
'vue',
'bootstrap-vue',
'vuex',
'vuex-localstorage'
])
// Set include paths but I still get errors
.sass('src/styles/app.scss', 'styles/', {includePaths: ['dist/assets/']})
.copyDirectory('src/assets', 'dist/assets')
.options({
// Turn off process css urls but I still get errors
processCssUrls: false,
uglify: true
})
.version();

VSCode and ES6 warnings

I keep on getting ES6 jshint warnings, for example:
''import' is only available in ES6 (use 'esversion: 6'). (W119)'
source: 'jshint'
code: 'W119'
I followed suggestions such as
Adding a .jshintrc file in the root with
{
"esversion": 6
}
Adding the following to the user and\or workspace settings:
"jshint.options":{
"esversion":6
}
But I still get the warning. Are there other things that I can do?
Thanks
Add a file .jshintrc into your project root, the warnings will disappear.
{
"esversion": 6
}
jsHint's ES6 warning can be solved easily by the following JSON code without creating any new file:
Paste the code inside the JSON editor of the "user settings".
"jshint.options": { "esversion": 6 },
jsconfig.json file which defines the JavaScript target to be ES6
I create a jsconfig.json file under my project directory and add codes in it:
{
"compilerOptions": {
"target": "ES6"
},
"exclude": [
"node_modules",
"**/node_modules/*"
]
}
According to the JSHint documentation: https://jshint.com/docs/ "In addition to using configuration files you can configure JSHint from within your files using special comments. These comments start with a label such as jshint or globals..."
So, a /* jshint esversion: 6 */ comment will work on the top of each file targeting ES6.
This have the advantage of you can switch these directives on and off per file or per function: "These comments are function scoped meaning that if you put them inside a function they will affect only this function's code."

My LESS sourceMap file is missing the "file" when run through grunt

When I run lessc --source-map=styles.map assets/less/00_style.less dest/assets/prod.css in the command line, everything is working. The styles.map file ends in:
...AV2rEF;EAAiB,aAAA","file":"dest/assets/prod.css"}
However, when I run grunt less, the styles.map is missing the "file" part and just ends in:
...AV2rEF;EAAiB,aAAA"}
This stops the SourceMap from working. What could be going wrong? My less config is as follows:
less: {
dist: {
options: {
sourceMap: true,
sourceMapFilename: 'styles.map'
},
files: [{
src : 'assets/less/00_style.less',
dest: 'dest/assets/prod.css'
}]
}
}
Short answer:
Add the following additional option to your less Task in Gruntfile.js:
...
options: {
...
sourceMapURL: '../../styles.map'
},
...
Long answer:
When running the lessc command via the CLI, (as per your example), notice the the following comment is written to the resultant prod.css:
/*# sourceMappingURL=../../styles.map */
However, when running the grunt task, (using your current config), the following comment is written into the resultant prod.css:
/*# sourceMappingURL=styles.map */
Note the missing ../../ - therefore prod.css can't find styles.map
This is why your SourceMap isn't working and not so much to do with the "file:" missing in styles.map when run via grunt. The .css file ultimately points to the .map file - not vice versa.
Even after running the lessc command via the CLI then deleting the "file:" part from styles.map you will find that the SourceMap still works in the browser. Indicating that the "file:" part, whether included in the .map file or not, has no effect on preventing the SourceMap from working.
Besides, as noted in the most recent proposed SourceMap spec (v.3) the "file:" part is optional:
Line 3: An optional name of the generated code that this source map is associated with.
Explicitly defining the sourceMapURL in your grunt Task options will entail having to keep a flat folder structure inside the dest/assets/ directory if you intend on using multiple .less files. (I.e. You'll need to avoid saving any resultant .css files in subfolders)

UNCSS keeps aborting with "src files were empty" message

I keep getting this error with UNCSS: 'Warning: Destination (dist/css/main.css) not written because src files were empty. Use --force to contine. Aborted due to warnings.
I believe it's running the task fine and is set up properly. I can use grunt for other things.
In gruntfile.js, I've included: grunt.loadNpmTasks('grunt-uncss');
and
uncss: {
dist: {
files: {
'dist/css/main2.css': ['../index.html']
}
}
}
I'm not sure what's wrong, but I think it's the pathing, but that's just how it is. I'm also using SCSS, so maybe it needs a raw css as SRC? I've tried reinstalling PhantomJS and the raw UNCSS without Grunt, but I'm going no where! Any ideas?
I found the solution.
It wasn't necessarily the pathing, but how the pathing was presented.
I was using
files: {
'dist/css/main2.css': ['../index.html']
}
I switched to
files: [
{ src: 'index.html', dest: 'dist/css/main.css' }
]
Here, the src & dest are declared.
This blog helped me deanhume.com.
The github/NPM documentation didn't work for me, but this guy's did. I hope this helps someone!

Grunt - Command Line Arguments, not working

I am using command line options in my grunt script: http://kurst.co.uk/transfer/Gruntfile.js
However the command grunt --vers:0.0.1 always returns 'undefined' when I try to get the option:
var version = grunt.option('vers') || '';
Can you help me get this working ?
I tried different (CLI) commands:
grunt vers:asd
grunt -vers:asd
grunt vers=asd
as well as using :
grunt.option('-vers');
grunt.option('--vers');
But no luck so far. Hopefully I am missing something simple.
This is my package.js file:
{
"name": "",
"version": "0.1.0",
"description": "Kurst EventDispatcher / Docs Demo ",
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-yuidoc": "*",
"grunt-typescript": "~0.1.3",
"uglify-js": "~2.3.5",
"grunt-lib-contrib": "~0.6.0",
"grunt-contrib-uglify":"*"
}
}
The proper syntax for specifying a command line argument in Grunt is:
grunt --option1=myValue
Then, in the grunt file you can access the value and print it like this:
console.log( grunt.option( "option1" ) );
Also, another reason you are probably having issues with --vers is because its already a grunt option that returns the version:
★ grunt --vers
grunt-cli v0.1.7
grunt v0.4.1
So it would probably be a good idea to switch to a different option name.
It is worth mentioning that as the amount of command line arguments you want to use grows, you will run into collisions with some arguments that grunt uses internally.
I got around this problem with nopt-grunt
From the Plugin author:
Grunt is awesome. Grunt's support for using additional command line options is not awesome. The current documentation is misleading in that they give examples of using boolean flags and options with values, but they don't tell you that it only works that way with a single option. Try and use more than one option and things fall apart quickly.
It's definitely worth checking out

Resources