My front end is an Angular 1.x project with tons of files. I basically need to validate it and find any errors that are there in any of the files. Specifically, errors that can break the page. In compiled/static type languages like Java, this is very easy, as the compiler will tell you exactly what's wrong. However, since JS is interpreted/dynamically typed, I can't figure out a way to "build" these files and find errors like I would for compiled languages. Going to every single page in the browser after I make any change is neither practical nor scalable.
I am also not using TypeScript or ES6 and it's not possible at the moment to migrate to any of them. Tools like ESLint and JSHint have also not been very successful, since they only bring out minor errors within that file. However, a lot of major code is spread over several files. Although my code is already all ES5, I thought about concatenating all JS files together in one file and running babel on it. But have it been sure how to manage dependencies during the concatenation (such as in what order to concatenate files).
This cant be the only project that uses vanilla JS and needs to be validated for errors. Anyone has any ideas on how I should go about accomplishing the task?
I highly recommend writing tests using jasmine and karma. I've found the two of these integrate really well with Angular and test driven development is highly regarded as one of the best development styles.
With all of this being said, I understand that's not what you're looking for directly because you want more of a "compiler" like solution. The closest thing that you can get to this in JS in my opinion is a linter and when combined with tests, this solution is rather good at finding errors in JS code.
Related
I started using react as my ui framework of choice. Upon my adventure through the documentation I noticed that when using the create-react-app script to spin up a new react boilerplate, they used .js file extension on scripts that where returning jsx code. When I asked my buddy he told me that you should use the .jsx extension on scripts that are returning this kind of code.
Im a bit lost here as if both works, wouldn't it just be better to go with the .js extension as at the end of the day its javascript we writing.
Please help me with what is considered best practise. (I kinda have a feeling it would be to use the .jsx extensions on these types of scripts, but I'd love to hear the community's view on this)
Thanks in advance :)
It's really up to personal preference.
My personal opinion is JavaScript is JavaScript, and I just use .js. Others will prefer to use .jsx in files that are JSX and .js in for things like utilities, in order to differentiate. The only important thing is to be consistent in whatever you choose (at least within one project).
In general, it doesn't matter.
The only time it might actually matter is based on your build pipeline. Some build pipelines may be configured to compile .js and .jsx with slightly different rules, but that would be based on your application (things like create-react-app don't care).
At the end of the day, you could use a .cookiemonster extension and it'd work just fine (as long as your build pipeline is configured to handle it).
Actually it doesn't matter, is up to you to decide I prefer to use .jsx when I return the mix between HTML and JS and use .js only when I'm using plain JS or ES6.
I recommend you to read about this on this issue on github.
I have quite huge project (production bundle file is around 400kB) written in coffee script. And I have no idea how to plan migration to ES6. I know that there are tools like Decaffeinate but I am not sure if it really works in bussiness practise.
I suppose that I can use ES6 and coffee in one project but is it possible to write components in coffee which import and use code written in ES6 and vice versa and all works in production?
Is this migration possible to be done step by step or there is no other option than doing everything in one release?
How does webpack work (proper loader)? What is the sequence? Does it firstly convert ES6 to JS (or coffee to JS) and then do all imports or import files first and then convert to JS?
Finally are there some best practices to have code written in both coffee script and ES6 in similar situation?
I'm the main person working on decaffeinate recently. It has been used on large production codebases and currently has no known bugs, so it's likely stable enough for you to use it. Still, you should convert your codebase a small piece at a time rather than all at once.
You can configure webpack to allow both CoffeeScript and JavaScript in the same project by specifying coffee-loader for .coffee files and babel-loader for .js files in your module.rules (or module.loaders for webpack 1).
If you use require syntax, importing code between CoffeeScript and JavaScript should just work without any problems. If you use JS import/export syntax, you may need to use require('./foo').default in some cases when requiring JavaScript from within a CoffeeScript file. But in most cases interop should just work even with import/export syntax.
Probably a good idea is to convert one or two files and make sure eslint, babel, and other JavaScript config are configured they way you want them to. From there, you should convert the code one or two files at a time, and increase the number of files you convert at once as you get more comfortable with it and depending on what your needs are.
One approach is to convert CoffeeScript files to JS slowly over time, converting and cleaning up the ones you touch. The problem I've seen with this approach is that it can be a very long time before you move off of CoffeeScript. It depends on your situation, but generally I would recommend running decaffeinate in larger and larger batches without focusing too much on manual cleanup, then once the codebase is 100% JavaScript, manually clean up files as you work with them.
A while ago, I wrote up some thoughts on how to think about different conversion strategies, which you might find useful:
https://github.com/decaffeinate/decaffeinate/blob/master/docs/conversion-guide.md#converting-a-whole-project
Problem I'm trying to solve:
I have multiple bundled JS files: head.js, footer.js, some-other-page.js
If I had these all in a single file I could easily check for dead code and strip it
I'd like to be able to still strip the site-wide dead code from each smaller bundle.
Willing to re-work my build to do this. Any ideas?
A good way to check about dead-code is by having unit-tests to your project and then check the code coverage and see which part was never used. For more about code coverage you can see: https://www.jetbrains.com/webstorm/help/monitoring-code-coverage-for-javascript.html
This will maybe need re-work of your code as well if you are not using unit-tests but it is a very good way to analyse your code for code coverage and see that some parts are never used (hence remove them from your code)
Also for code that it is not yours (e.g. for jQuery) you can use a grunt build to remove the functions/methods that you are not using. A very interesting article of how to do that is this: http://developer.telerik.com/featured/trimming-jquery-grunt . For example if you are not using the ajax from jQuery you can simply do this: grunt custom:-ajax. Known libraries has this functionality so you can build it on the go.
Well,
Good Idea but for understanding purpose it's good to keep it seperate but if you want to combine then use switch
I am using jquery fileupload plugin and it has 7-8 js files which it loads.
Now others developers are also working on site and sometime it cause confusion and difficult to find which js file is used where.
So i am thinking if i can combine 7 files in one file so that i can know that thats my file
Try this to compile your javascript file or code.
http://closure-compiler.appspot.com
While possibly overkill in this particular case, it might be worth checking out grunt. It will let you keep your files divided into multiple files for when you are working on them, and as soon as any file change compiling, minifying and combining them into a single/groups of files as desired, while also allowing you to define the load order of your code.
It requires some setup the first time you run it (which you can later use as a template) but greatly improves the process of combining/minifying files, and also has support for processing coffescript and sass among others, as well as writing unit tests for your code.
I use Rake to compile Javascript (and SASS to CSS, as well). It minifies the files in a unique JS. It's written in Ruby, but it's easy to configure and it works very fine.
But if more developers are working on the same code, another good idea I strongly suggest is to to use a SVN (sub-version control system), as TortoiseSVN or Git. This will allow many developers to work on the same source files, without losing any change.
I am working on a rails project that has too many javascript files. Processing this script takes too much time. I want to remove the unnecessary javascript includes from my application. I am familiar with the plugins that can find unnecessary css but I haven't come across any method of finding unused javascript. If anyone has any idea regarding this please share.
Thanks
Are you referring to rjs (Rails-generated) or standard js files? If it's the latter then you can use jslint. For the first type you should have some integration tests that fail when you remove the RJS that is being used, if not you'll have to add those tests first.
For more see: Is there a tool to remove unused methods in javascript?