I am looking for a solution that helps me achieve this:
I would like to have at 'build' time an error throwed if I try doing this:
var ciao = {
wow: 'ciaoooo',
}
console.log(ciao.wowe); // this should be an error because the prop does not exist
I have tried Typescript and it does the jobs, but it seems an overkill use it only for this. I was wondering if there was something for ESLint or something else that can help me with this type of problem.
You're asking for features of a statically typed language. If you want reliable information about variables on build time, you'll need this "overkill" of defining interfaces and types. TypeScript, however, is optionally typed, which might be a good compromise if you want static types for your public interfaces.
If you want type checking but don't want to use a transpiler, you could also try Flow which tries to derive type information just from your code as much as possible. However, its capabilities without additional type information are very limited.
Concerning your actual question: I think it would be possible to derive type information within module (or file) boundaries with ESLint or Babel. As long as you are using that object just within these boundaries, static analysis can probably help you. But beyond that, I don't think it's reliably feasible because of the dynamic nature of JavaScript. Unfortunately, I don't know such a rule or plugin.
ESLint doesn't have a rule like that. It would be very hard to create a rule that would be able to catch all possible cases for this. ESLint relies on Escope to track declared variables, but Escope doesn't track object properties, and there are just too many ways to add a property to a declared object.
Related
It seems like the environment variables in app.yaml are rendered in Python-like strings, where booleans like true become True and empty variables becomes None. Anyone have ideas on how to make it play nice with javascript without doing explicit conversion for all my variables?
const MY_ENV_VAR = (process.env.MY_ENV_VAR === 'None') ? null : process.env.MY_ENV_VAR;
Yes, I can write some function to do it. Wondering if anyone has a clever solution.
The only additional available configurations related to Javascript are for Node.js and they are quite simple. As per the official documentation of the app.yaml file, the option Javascript related is to set the runtime and that's it, unfortunately. There is not direct way to configure better usage for the environment variables.
Considering that and that, I agree with you, having better handling of environemt variables in Javascript would be better for a lot of cases. Due to that, I would recommend you to raise a Feature Request in Google's Public Issue Tracker, so they can take a look at it and verify the possibility of implementing it in the future.
Let me know if the information helped you!
I come from the Java world, i.e. a typesafe world and am right now doing a couple of things for which I need client side execution using javascript.
I keep running into pretty hard to detect errors at times due to the non typification of JS and am wondering if there is any way to prevent it beforehand. E.g. setting sth like "use typification;" or via some tool that does these checks before executing like a compiler does.
E.g. last time was when I was creating a face in three.js. There depening on order of vertices a face is front-facing or not. I had mixed that up and then copy pasted parameters in which case I also copied a bracket too much so it ended up in the wrong place with just calling the method with one instead of three vertices which of course resulted in an error. However in line 2107 of three.js code and it took a while to figure out this little copy paste issue. Comparing to java the compiler would have directly complained that i try calling the method with 1 instead of 3 parameters...
Hope there is sth like it. Or do have some tips how to spot such things faster?
Cheers
Tom
There are various linting tools which you can use to scan your javascript files before you actually use them. The popular ones in the industry are JSLint, JSHint, JSCS and ESLint.
They come inbuilt with various rule sets which you can configure and you can also add your own rules.
You can compare these to checkstyles and PMD from the JAVA world.
You have a number of answers. But first, need to clarify: Java is not type-safe (see: NullPointerException, history of).
But to get closer to type-safety in any dynamic language you have the option to pepper your code with asserts. This can to some degree be automated, it may cause performance issues. This is the route I usually take, but I certainly wouldn't do it with three.js.
For JavaScript specifically, you have two additional options: TypeScript and Flow.
TypeScript is a dialect of JavaScript with type annotations that gets compiled down to plain JS. Flow is a static analyzer written in OCaml that tries to infer types in your JS code and check them.
The Google Closure Compiler is a powerful compiler and minifier for JS, which gives a lot of optimization options such as renaming variables, removing dead codes, collapsing variable declarations, rewriting control flow structures and etc.
What I want is to separately apply one or some of these optimizations on an input JS program. For example, I may want to rename variables with short names, but not to remove dead codes. How can I achieve this kind of detailed compilation pass control? Does the source code of CC expose specific interfaces to do this customization, or I should write my own pass(If so, how am I supposed to start?).
The command line features do offer several options for controlling the compilation, but are insufficient to fit what I want above. Since the source code is kinda complicated and few detailed design documentation can be found, I am truly stuck here. Any insights would be appreciated, thanks :)
Take a look at DefaultPassConfig. That class lists all the passes that are run during the compilation, based on what options are set in the CompilerOptions. Some of the CompilerOptions can be controlled from the command line, but we generally try to keep the compiler relatively simple and easy to use, and not ask users to make decisions about a bunch of different compiler flags. Plus, there are some passes that actually increase the code size, but they do it in such a way that it makes it easier for some later pass to decrease it afterwards.
Of course if you're just experimenting with the compiler or trying to understand how it works, you can turn on and off whichever passes you want, either by adding new flags, or just modifying DefaultPassConfig directly.
What is best practice for naming custom property in ExtJS?
Is it a good idea to precede name with an underline?
Ext.create("Ext.Window,{
height:50,
_custom:"xxx",
_action:"yyyy"
});
another idea is using data_ prefix to mimic html5 custom attribute convention.
I personally don't like anything in a variable name that carries additional syntactic information (Uncle Bob dedicates a whole section to this principle in http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882), not to mention the ugly code it produces (e.g. mywindow._custom).
I would just give your variables descriptive names, and then your code will read better and you shouldn't have to worry about collision with Ext properties (if you were worried about).
I like this much better:
Ext.create("Ext.Window,{
height:50,
customNameOfSomething:"xxx",
actionToPerform:"yyyy"
});
Agreed with others, and will add that the underscore in particular is more or less an accepted standard for private variables in most syntaxes (though Ext JS itself does not use it, and keeps private variables marked as private via comments or undocumented by convention). I definitely would choose some other way to name public configs if you insist on choosing some convention, though I agree with others that it's probably not necessary. I would guess that in most real cases, your custom properties are not going to be so generic as to clash (and if they are, you probably chose poor names for whatever you're adding).
You have to remember that you're designing a custom property that might be used by others. This means that it has to be descriptive of its behavior. That's what is most important. Using an _ is very rare and isn't really natural to developers using the code, so it's gotta be user friendly.
I decided to to use _ as a prefix for custom variables. because:
It prevent any collision
Self-documenting
It's users friendly
It would be better if Sencha used a mechanism to prevent the mixing up.
Is there a way to read a set of JavaScript files, and output a description of where every function/method is defined?
I realize that this is likely impossible in full generality, due to the extreme dynamic nature of the language. What I'm imagining is something which gets the (relatively) straightforward cases. Ideally, I'd want it figure out where, e.g. some method got attached to string or hash or some other fundamental class (and also just let you find all the classes/functions that get defined once in one place).
Does such a tool exist?
Give Eclipse (with JSDT) or Aptana a try.
The Outline view of a JavaScript file gives great view of functions and object hierarchies.
Granted this will only work for a single js file, and it sounds like your looking for more of a report, so I guess I need to ask what your ultimate goal is.
I'm not sure if it will output anything without documentation comments, but you could give YUI Doc a try.