New to WebOptimzier and curious if it can remove calls to console.log, console.warn, etc. during the minification process. I don't see any reference to it on the site but hoping it is buried in there somewhere as other bundle/minify tools have it.
Related
I'm writing a single-page JavaScript application and I'm using Atom as my text-editor. (It's an Electron application, but that's besides the point.)
I'm also using the linter-jshint plugin for Atom. This is great, as it shows immediately in the text-editor when I make a typo in a variable, among other useful things.
Lately, my app has been getting very long. Naturally, I want to try and split it up across multiple files. After doing some research on StackOverflow, I've determined that I can use Grunt to automatically concatenate JavaScript files together. This is great because I don't have to refactor my code - I can just copy paste my existing functions into separate files. Easy!
However, once I do this, Atom fills up with warnings and errors from JSHint, because it can't find variables and functions that are located in the other files!
Now, I could just abandon the JHint plugin in Atom altogether and use the JSHint plugin for Grunt after the concatenation has already occured. But that sucks! I want the code that I'm going to be writing to be checked on the fly like a real IDE.
Is there a way to tell Atom/JSHint to assume that a bunch of JavaScript files will all be concatenated together? Or am I just approaching this problem completely wrong?
You can split your electron application with Node Common Modules, and use require('./state.js'); within your application.
Although I don't use Atom, that should allow for it to understand how you're using your variables and functions in other files.
Also this should eliminate your need for concatenation as the single-page app will have all it's dependencies accounted for.
well the question is, exist some app or language/etc to write a custom syntax to can check files?
You know, when we works in different places, ppl and projects every one have differents rules to how write, code style and all that things, the idea its can check all this things because at least to me normally i forgot something.
Ideally some app without a heavy GUI, thinking maybe a terminal app, or editors like gedit, avoid plis apps like Eclipse and similars.
For now i need only check simple parts, if you can recommend both a simple/limited app and a complex/full app would be great.
Obvs, if exist a simple/full app, will be better.
Thx.
If what you're looking for is a program that rewrites a source code given a specific coding style, I advise you to take a look at GNU Indent.
If you want to do more complex operations like build an AST and work on it to add things, edit, check for existing dependencies or whatever, you'll want to use a tool like Flex/Bison, Clang, Pyrser, etc.
I've been developing a lot of small web development projects in various IDEs, and find myself laboriously typing in jslint configuration headers to silence JSLint. Its warnings and errors are all valid, and I want to keep JSLint in my work cycle, but I spin up 2-3 isolated environments a day, sometimes from generators in Yeoman, other times by hand. These all end up with gripes from JSLint that require the following in every .js file:
/*jslint browser:true*/
/*global require,yada,yada,yada*/
JSHint has a wonderful feature whereby you can declare all these in a parent folder using the body of the .jshintrc file. Does JSLint have something like this? It seems like such an obvious addition, but I can find nothing like this which will work across IDEs (Visual Studio, IntelliJ, Brackets, Sublime Text,...).
I found this for .NET, but I find Visual Studio heavy for projects I might only spend a couple hours on and then throw away (https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings).
Does someone have some insight on this?
Edit: (See my new answer below.)
I think the quick answer is that setting global settings for every file you JSLint is the job of your IDE or favorite text editor. That is, JSLint is essentially just a big javascript file. It doesn't care about file paths, etc, and won't look for a server-wide config.
I mean, you can change the options used when JSLint is called, but that essentially reduces to the same problem you have now.
So then the question is, if you don't like Visual Studio, what tools do you use? In VS, I've used this tool and liked it a good deal. I think that's different (as in not forked or related, but I could be wrong) than the one you found. In Sublime Text, there are two. I've been using Darren Deridder's, but I get the impression that it's the less popular of the two. Etc etc.
So this isn't a javascript/JSLint question so much as a JSLint wrapper question.
It should be said that JSLint's code is very clean, and it's easy to rig up your own process using Node or something similar. I've done it with JavaScript.NET, though I'd use Node if I was doing it again.
And I'd also suggest you consider keeping the file-by-file JSLint headers. I tend to do so, and it keeps your use "excuses" to a minimum, keeping your code tighter. It's way too easy to get a giant /*global ...*/ header line, for instance, if you have a lot of shared config info. It also means that when someone else uses a "shell" tool different than yours to JSLint your files, you know they're using pretty close to your intended accepted behaviors.
So the literal answer to your question is, "No, JSLint doesn't inherently support a box-wide config file." The longer answer is, "Tell us where you do like to work." ;^)
EDIT: Debated staying out of the usual 'Hint vs. 'Lint discussion, but I will quickly say I like how you're thinking. JSLint is more draconian, but JSLinted code means something more specific than code that's been JSHinted. I won't argue that more specific means better, per se, but I will say that I see JSLint's draconian-ness to be an advantage. It might not be the only way to do something, but there's nothing that Crockford's telling you that's a bad idea, and it's nice to get familiar with those conventions. In the parlance of my times, Crockfords's not wrong, Walter.
EDIT 2: So Brackets looks like it's come a long way since I last used it. Seems to have JSLint by default.
It looks like you can set global JSLint options using the jslint.options setting in your preferences file (and there might be/have been a goal to make that a more interactive UI eventually), like this...
{
"debug.showErrorsInStatusBar": false,
"styleActiveLine": true,
"jslint.options": { "sloppy":true, "white":true, "browser": true }
}
And it does allow settings at the top of the file to override these settings.
This really is approaching a golden age of text editors. I still fall back on VIm a lot, but mainly live VS and Sublime Text, with even jEdit, Coda, and PhpStorm for specific tasks. Looks like this might be my new Sublime for Node & html frontend dev. The quick CSS edit is wonderful, though bindings will complicate it. Thanks!
While the previous excepted answer is an excellent one (and many thanks to its author for making it even better over time!), the world has moved on from JSLint. I'd recommend to anyone reading this very old question that you seriously consider chucking JSLint out of your development cycle in favor of its very effective successor, ESLint. For an even better experience, I'd suggest taking a hard look at the ES7 vs. TypeScript paths, with TSLint being your best option for TypeScript linting.
However, for the development experience that trumps even these modern libraries, go directly for Prettier.js. With Prettier, your linting woes become irrelevant, since Prettier will rewrite your code in an opinionated manner every time it's run.
For the best results with Prettier, add the packages "lint-staged" and "husky" to your dev-dependencies, then add the following in your package.json:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,json,css,md}": [
"prettier --write",
"git add"
]
},
This will force Prettier's auto-linting behavior to run every time Git's commit command runs.
I can't tell you what a relief using Prettier has been for the front-end development teams and projects I am responsible for. We've gone from code reviews bleeding with linting correction comments to zero almost immediately. Feedback from the teams has been universally positive.
The only modification I've made has been to the tabs-vs.-spaces setting. I've modified my .prettierrc.json file to select tabs instead of spaces, because use of spaces at different widths causes dirty git merge histories. You can't control the indentation of 250+ developers spread over multiple hemispheres, some of whom drop in and out of the project before you even know their names. So, setting tabs as the default indentation allows all of the developers to operate with the indentation they're comfortable with without modifying lines in Git. Here's my .prettierrc.json file, with some other slight modifications:
{
"arrowParens": "always",
"bracketSpacing": false,
"singleQuote": true,
"useTabs": true,
"trailingComma": "none"
}
As my Meteor project grows and I add more templates, partials and helpers, it gets harder to figure out what will be the data context for it. Then I'll have to console.log(this) inside a helper function to figure out what's the data I'm dealing with.
Does anybody have a naming scheme or any other strategy to handle this?
Or is this mess just a sign I'm failing to modularize stuff properly and should refactor everything?
For me, each module has a folder. Each folder contains helpers.js, events.js, the "ons" (onCreated.js, onDestroyed.js, onRendered.js) and finally templates.html. If your project is big, break these out into individual subfolders for the necessary CRUD actions (I have a create folder and an update folder because reading & deleting happens in the update templates.
My template names are long and verbose, but that's OK, WebStorm does a good job of guessing what I want. For example, if I had some infowindow that listed all the addresses associated with a client: clientMap, clientMapPopup, clientMapPopupLocationList clientMapPopupLocationListItem.
Regarding data context, it's usually pretty easy to see since my helper is the one that added something to the context. Although I honestly try to avoid using that unless I'm in an {{#each}} because IMHO things like grabbing grandparent context is neither elegant nor robust. Instead, I have a temporary module object that I create & destroy on route changes.
So if my global object is Global = {}. In the onCreated and onDestroyed I write Global.Module = {} Then, I can create all the module-scoped variables I want (ReactiveVars, ReactiveDicts, local collections, primitives, client markers object, etc).
All that said, doing what you do & looking at my schema js (e.g. collections/clients.js) is still the fastest/thoughtless way to see what you want & what you're currently getting.
I'm using reactive extensions (well, trying, learning) in a windows store app. I have a series of async operations that will eventually navigate to an authorization web page for RTM. Given the reading I've done, I would expect to write something like the following:
var result = rtm
.GetFrob()
.Select(s => rtm.GetAuthenticationUrl(s))
.ObserveOnDispatcher()
.Do(uri => AuthWebView.Navigate(new Uri(uri)))
.First();
However, I can't seem to find a method ObserveOnDispatcher, and further there is no Scheduler.Dispatcher property either, leading me to think on a Windows Store application there is something deeper gong on with the main UI thread and how you reference it.
GetFrob, btw, creates an IObservable sequence using Observable.FromAsync (if that helps with this).
BTW, if I remove that line, I fail in the call to the Navigate as posting it from the wrong thread. So, what is the proper thing to do here to make sure I'm back on the correct thread?
BTW, Excuse the ".Do" operation here, I know it isn't "nice", however, I'm still experimenting in throw-away code.
Many thanks in advance!
Argh. Apparently I just am not good enough at search. :(
Turns out that adding the nuget package Rx-Xaml includes the proper assemblies for the scheduler, etc. Details can be found on the main Rx blog. Of course, my app is back to hanging now, but that may be due to something else dumb on my part.