I am working with Ext Js and Visual Studio. With _references.js I can get the intellisense working. I can add a definition for "Ext" in here for JsHint:
But it still thows 500 errors about ext-all-debug.js
I am wondering if using JsHint here adds any value to my project. Visual Studio seems to take care of true JavaScript syntax errors.
Some examples of the warnings:
JsHint (W116): Expected '===' and instead saw '=='.
or:
JsHint (W083): Don't make functions within a loop.
Should I disable JSHint completely or try to configure it better?
When a major framework does not respect the rules then why should I?
Update:
In web essentials you can create a file called something.weignore. It follows the same syntax than .jshintignore.
Source: http://vswebessentials.com/features/general
You definitely shouldn't be running the linter over ext-all-debug.js. Ignore that using a file called .jshintignore in the root of your project and put the path of ext-all-debug.js in there. An example of the content of .jshintignore could be:
content/js/extjs5.1/ext-debug-all.js
content/js/jquery.js
This would tell jshint to ignore jquery.js and extjs. You can also exclude whole directories. Take a look at the jshint ignore for the jQuery project:
https://github.com/jquery/jquery/blob/master/.jshintignore
external
src/intro.js
src/outro.js
test/data/jquery-1.9.1.js
test/data/badcall.js
test/data/badjson.js
test/data/json_obj.js
test/data/readywaitasset.js
test/data/readywaitloader.js
test/data/support/csp.js
test/data/support/getComputedSupport.js
Maybe Ext JS is working to address those errors internally, maybe they just don't care. But don't let another person's code practises negatively affect your own. If you feel you'll be writing better code by using jshint then use it! There are good reasons behind the warnings you are seeing.
Related
I know ReactJS converts __DEV__ into "production" !== process.env.NODE_ENV - like this. I saw somewhere that it's converted directly to a boolean, depending on the environment, but that's another confusing point.
I was wondering, though, what specific babel-plugin/process/packages actually removes this condition from the production React (react.min.js), because there are no such conditions in that file.
From my understanding, it's a two-step process:
using a Babel plugin, convert warnings and invariant calls into if
("production" !== process.env.NODE_ENV) calls
remove the
entire above conditions (or just its truthy branch?) in the production build, when minifying
How/where is the latter implemented?
ReactJS uses Webpack to bundle its production code.
Webpack has a plugin called DefinePlugin, which ReactJS uses. This plugin replaces literal values in the code, values that you can control. Very similar to compiler inlining.
Either I don't get the name of this plugin, or it's just a poor choice. In my research trying to find out how ReactJS cleans up its production code, I've more than once skimmed over the new webpack.DefinePlugin() call. Also, my lack of experience with Webpack didn't help.
As mentioned in the plugin page it's a multi-step process:
1. Original code:
if (!PRODUCTION) {
console.log('Debug info');
}
if (PRODUCTION) {
console.log('Production log');
}
2. Inlining done by the Define plugin:
if (!true) {
console.log('Debug info');
}
if (true) {
console.log('Production log');
}
3. Minification step, and the final result
console.log('Production log');
The minification/optimization step is done through a tool called Terser, which is what Webpack is using. Terser looks like a fork of UglifyJS, and it, too, has the ability to remove dead code.
So it's:
ReactJS compile production
React configures Webpack with DefinePlugin process.env.NODE_ENV = 'production'
Webpack inlining, done by the Webpack's DefinePlugin
Webpack optimizing
Webpack Terser plugin
Terser finally removes dead code
I'd like to thank #romellem for pointing me in the right direction through this jungle.
PS: Dear future readers, I've written this in the 10th of May 2019. My findings are probably going to be obsolete soon.
The code is removed when the JS is uglified (minified).
UglifyJS2 has an option dead_code that "remove[s] unreachable code."
As to how this works, the logic here is fairly complex, but a starting point would be Uglify's eliminate_dead_code function.
I just updated Visual Studio 2017 from RC to final. I didn’t get the following error but recently I get this error. In building the project, I get the following error and it prevents the web project to start:
Severity Code Description Project File Line Suppression State
Error eqeqeq (ESLint) Expected '===' and instead saw '=='. VistaBest.Shop.Web C:\***\Request.js 21
How can I disable JavaScript building error in Visual Studio 2017?
I think, find the solution:
Open Tools > Options
Navigate to Text Editor > JavaScript/TypeScript > EsLint (in VS2017 15.8 it is Linting not EsLint)
Set Enable ESLint to False
Visual Studio >= 15.8.5
In Visual Studio 2017 (v 15.8.0):
Option 1: Options > JS Errors
Open Tools > Options
Navigate to Text Editor > JavaScript/TypeScript > Code Validation
Set Enable JavaScript errors to false
or, set Enable JavaScript errors to true and Show errors as warnings to true
I needed to restart Visual Studio for this to take effect.
Option 2: Options > Linting
There is another option below which will let you edit your global linting settings:
Option 3: .eslint file
You can also create a file named .eslintrc in the root of your project.
Option 4: ESLint commands in-file
See #user9153924's answer
Resources
ESLint file syntax
ESLint Rules
I tried Mohammad`s solution but it didn't work. I managed to work doing the following:
Righ click on your web .csproj file
On the first <PropertyGroup> add the following entry:
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
Add /*eslint eqeqeq: ["error", "smart"]*/ to the first line of your Javascript code to remove the errors.
https://eslint.org/docs/rules/eqeqeq
Following Mohammad's solution will turn off ESLint for syntax checking. This works in VS2015 and should work in later versions.
For Visual Studio 2019.
Open Tools > Options
Navigate to Text Editor > JavaScript/TypeScript
=> Linting > General.
Then unchecked ESLint check box.
Please The bellow Image for reference.
I've just had to change the "eqeqeq" rule behaviour to include "smart":
Edit the .eslintrc file found in your user root folder mentioned in other answers already.
The change is made to the rules section by adding the smart rule
"rules": {
"eqeqeq": [2, "smart"],
Copied from the web article:
This option enforces the use of === and !== except for these cases:
Comparing two literal values
Evaluating the value of typeof
Comparing against null
I found the specifics at:
https://eslint.org/docs/2.0.0/rules/eqeqeq
I tried Mohammad's solution but with no luck, I followed Rafeel answer and instead of adding his suggested code sample I removed below code from web .csproj and finally I was able to build and run my project. There were two places where you should remove that in the same file. Still, I don't have any clue how the removed code will affect my solution.
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
Hope this will also help someone to save the day..!!!
In my Angular JS app, I'm using a lot of third party packages, mainly maintained via Bower.
When I use Grunt to concatenate all of them into one mega file, I'm getting errors when I load my page, for example that
Uncaught ReferenceError: angular is not defined and
GET http://localhost:8080/theproj/v4/dist/app/bootstrap.css.map 404 (Not Found)
What is the best way to properly concatenate all these files to ensure that everything loads in the right order and doesn't cause problems?
First issue: A lot of times third party libraries must be loaded in a particular order. That looks like like it's the source of your first issue. Something is trying to use angular and it's getting loaded before the angular code. You should refactor your grunt task to use a pre-defined order for third party libraries.
Second issue: You probably are missing the .map file. This is a file used by Chrome dev tools to show you the original source for the css (sass or less). Either provide the map file, or delete the reference to it from bootstrap.css. Or just ignore the error, it's only an error when you have chrome dev tools open, and doesn't actually affect your application.
For the issue of the correct order for your javascript files, i had that problem in a larger project where noone really had a clue which was the correct order.
Luckily we found that the Google Closure Compiler does exactly this: https://github.com/google/closure-compiler
You give it all your js files and it analyzes them all and concatenates them in order
$ java -jar compiler.jar --js_output_file=out.js in1.js in2.js in3.js ...
There is even a grunt plugin for the connection: https://github.com/gmarty/grunt-closure-compiler
'closure-compiler': {
frontend: {
closurePath: '/src/to/closure-compiler',
js: 'static/src/frontend.js',
jsOutputFile: 'static/js/frontend.min.js',
maxBuffer: 500,
options: {
compilation_level: 'ADVANCED_OPTIMIZATIONS',
language_in: 'ECMASCRIPT5_STRICT'
}
}
},
Another way would be to change your javascripts into AMD or CommonJS modules, this way you don't have to worry about the correct order. RequireJS (http://requirejs.org/docs/start.html) is a possibility for AMD for example or Webpack (http://webpack.github.io/) ...or many many others.
Has any one had any success with this?
I think it's more or less an unsolved problem:
https://github.com/jashkenas/coffee-script/issues/2779 . Last meanigingful comment was from jwalton, a month ago.
Still, it doesn't seem rocket science to add support for it, so it will probably come soon.
Michael Ficarra (creator of CoffeeScript Redux) suggested using https://github.com/michaelficarra/commonjs-everywhere .
Two caveats:
It only works for bundling CommonJS modules.
It uses CoffeeScript Redux, which is still in beta (although working quite well it seems), and not 100% compatible with original CoffeeScript compiler.
So this does not work for what you ask for specifically, "concatenation".
Added April 14
You might have luck with these: combine-source-map and/or generate-sourcemap, both by same author.
Added April 26
This looks really simple: https://npmjs.org/package/mapcat . You just have to feed it the individual source map files generated by the coffee compiler.
Added May 16
Mariusz Nowak has just released webmake-coffee. Like CommonJS Everywhere, it requires code to be organized as CommonJS modules. Unlike CommonJS everywhere, it uses regular CoffeeScript.
It also seems the Grunt Coffee-Script plugin has had source-map support for concatenated files for quite a while (two months), effectively proving my original answer to be incorrect.
The upcoming version 2.0 of Snockets will have support for it too.
I ended up going with browserify using coffeeify as the transform option, and enabling browserify's debug option. I bundle up the app on each request for my main.js file, and any runtime errors show up in my original source with pretty decent accuracy.
Sure beats mapping runtime errors in the concatenated/compiled js back to the coffee source with my eyeballs!
I needed to annotate AngularJS code before minification, but grunt-ng-annotate didn't accept input source maps, thus I would not be able to use maps generated by the CoffeeScript compiler.
Apparently, with gulp-sourcemaps this is not an issue:
var gulp = require('gulp');
var $ = require('gulp-load-plugins')(); // loading gulp plugins lazily
// remember to include them in the package.json
gulp.task('appJS', function() {
// concatenate compiled .coffee files and js files into build/app.js
gulp.src(['./app/**/*.js','./app/**/*.coffee'])
.pipe($.sourcemaps.init())
.pipe($['if'](/[.]coffee$/, $.coffee({bare: true}).on('error', $.util.log)))
.pipe($.concat('app.js'))
.pipe($.ngAnnotate())
.pipe($.uglify())
.pipe($.sourcemaps.write())
.pipe(gulp.dest('./build'))
});
The same approach works in other situations, too. In my case, this is the only approach that worked.
I have written a grunt task that does this flawless. Check it out
I have set up Syntastic https://github.com/scrooloose/syntastic with vim and I would like to use it for node.js javascript linting.
I have installed jslint
$ jslint routes/index.js
routes/index.js
#1 Expected exactly one space between 'function' and '('.
module.exports = function(app) { // Line 5, Pos 26
....
And I have put this in my ~/.vimrc
let g:syntastic_jslint_checkers=['jslint']
let g:syntastic_check_on_open=1
let g:syntastic_enable_signs=1
But I get no output on :SyntasticCheck
Yet
Syntastic: active mode enabled
Syntastic info for filetype: javascript
Available checker(s): jslint
Currently enabled checker(s): jslint
I recommend JSHint as an alternative for JavaScript linting in Vim. Here is a great answer that explains how to install it.
If you want to use JSHint for creating web sites as well, I'd additionally use RequireJS. This way your JavaScript and your HTML code stay separated (JSHint can't deal with JavaScript inside HTML files).