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.
Related
Sonarqube is displaying errors for empty css/scss files in the Angular application. What are the effects of having empty scss files? Do they cause issues with performance, side bugs/errors, future problems, what are the compound negative issues? These are generally leftover when we do ng generate component
Sonarqube flag: Remove this empty stylesheet
Article below states to ignore it, compiler will take care of it, however more interested in the effects of leaving empty files, if there are any.
Empty style (.css/.scss) files
Company would have to go through 1000+ empty scss files in large application, interested to know if its worth the time.
As far as I can tell from looking into this, the best answer is to just leave it. The compiler will indeed handle the empty files appropriately.
SonarQube is just picking it up as code smell, empty files should probably be removed to keep a project in its least complex state possible. In the example you gave with a company going through that many files it is a complete waste of time.
I come from the future and I face the same problem, our solution was to delete the files that were already empty and generate the new components with the --inline-style option, this way no css/scss files are created by default when create the components.
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'm trying to put together a Grunt task to build our JS assets as part of our build/deploy process. I'd characterize our needs as fairly standard, but serious (in that we need to support a real-world production app, not just a toy example).
We have a bunch of source files, some JavaScript, some CoffeeScript, in a bunch of separate files in a structured directory tree. We need to compile the CoffeeScript, and concatenate and minify all the code into several defined output files (i.e. all.js and vendor.js). And we need to end up with usable source maps to accompany this output that reflect the original source (the CS or JS files), preferably with embedded sourcesContent.
I'm having a surprisingly difficult time putting this together, and have yet to find an example of a Gruntfile that accomplishes all of these goals in a realistic build scenario. Has anyone accomplished this? It seems like almost any major Angular project that's building with Grunt would have a set of requirements that looks a lot like ours.
Right now I'm using grunt-contrib-coffee, grunt-contrib-concat, and grunt-contrib-uglify, and have something that's almost working but for all sorts of trouble with relative paths in the source maps. I've also run into problems with uglify not handling multiple source maps, and problems with each of those plugins having different capabilities when it comes to reading and generating source maps.
I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.
I have an unusual environment in a project where I have many files that are each independent standalone scripts. All of the code required by the script must be in the one file and I can't reference outside files with includes etc.
There is a common function in all of these files that does authorization that is the last function in each file. If this function changes at all (as it does now and then) it has to changed in all the files and there are plenty of them.
Initially I was thinking of keeping the authorization function in a separate file and running a batch process that produced the final files by combining the auth file with each of the others. However, this is extremely cumbersome when debugging because the auth function needs to be in the main file for this purpose. So I'd always be testing and debugging in the folder with the combined file and then have to copy changes back to the uncombined files.
Can anyone think of a way to solve this problem? i.e. maintain an identical fragment of code in multiple files.
I'm not sure what you mean by "the auth function needs to be in the main file for this purpose", but a typical Unix solution might be to use make(1) and cpp(1) here.
Not sure what environment/editor your using but one thing you can do is to use prebuild events. create a start-tag/end-tag which defines the import region, and then in the prebuild event copy the common code between the tags and then compile...
//$start-tag-common-auth
..... code here .....
//$end-tag-common-auth
In your prebuild event just find those tags, and replace them with the import code and then finish compiling.
VS supports pre-post build events which can call external processes, but do not directly interact with the environment (like batch files or scripts).
Instead of keeping the authentication code in a separate file, designate one of your existing scripts as the primary or master script. Use this one to edit/debug/work on the authentication code. Then add a build/batch process like you are talking about that copies the authentication code from the master script into all of the other scripts.
That way you can still debug and work with the master script at any time, you don't have to worry about one more file, and your build/deploy process keeps everything in sync.
You can use a technique like #Priyank Bolia suggested to make it easy to find/replace the required bit of code.
I ugly way I can think of:
have the original code in all the files, and surround it with markers like:
///To be replaced automatically by the build process to the latest code
String str = "my code copy that can be old";
///Marker end.
This code block can be replaced automatically by the build process, from one common code file.