While adding features and updating code in a file I like to simultaneously refactor the file from .js to .ts.
When looking at the pull request the final diffs show just the removed file and the added file, which makes a direct comparison of more highlighted code changes difficult. Even if the refactoring were done in a separate commit, latter changes to code would require multiple commit comparisons.
Is there a standard way (outside of IDEs like Webstorm, VScode etc) to compare refactors like this, TS-specific or otherwise, that might intuit the changes of note and allow for more streamlined reviews?
Hopefully this isn't a duplicate question, I couldn't seem to find one while searching.
I just discovered git mv which is the solution to this problem.
git mv path/to/file.js path/to/file.ts
Now your diff will work!
Related
I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE's (note 1).
Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?
My research points me to 'no', but a solution combining git hooks and Checkstyle/jrefactory might be possible.
So if 'no' to above, is there a tool/process that will perform the TBD process actions below?
The checkout process flow for User1 would be:
git pull
TBD process formats code to User1 style-1
User1 works in their preferred IDE with style-1 settings
The commit workflow for User1 would be:
User1 is ready to commit/push code
TBD process formats code to standard format style-standard
git push
Note 1: multiple IDE's = Eclipse, IntelliJ, Netbeans.
Note 2: My question differs from this question in that I'd like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.
Note 3: Acknowledging that this shouldn't be done for best-practices-reasons. However, if you grant that it's time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.
First of all, you really shouldn't do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don't have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn't solve the fact that they'll have to read code in a codestyle they don't yet like, but it's a lot safer than having invisible automatic code changes; that's a major source of bugs.
Maybe you can use Eclipse's code formatter from the command line to apply a different codestyle. You'd have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You'd need hooks both for post-checkout and pre-commit, one to set up the user's codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn't include style differences in git diff (although they will show up in git diff --staged).
Again, you shouldn't do that.
I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:
Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes.
So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:
And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):
It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.
Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes
I am wondering, if there is a way of using comments for my package.json dependencies.
Right now we have a bigger package.json file and we get more and more lost about the dependencies and there they come from. On other languages (not javascript) we can easily add comments. But since JSON is not supporting comments, this gets really tough for us.
Is there a optional file format for package.json to define our dependencies?
If not, how can we manage to create a package.json with comments?
Far more I am wondering, why node/NPM forces developers NOT to document, by choosing a fileformat which makes it impossible to document?!?
Hope someone can help us out of the dark...
I had the same problem earlier on this year.
I've just solved that problem with writing some basic script like this
#!/usr/local/bin/python
import os
os.rename("package.json", "package_M.json")
with open("package_M.json") as f:
with open("package.json", "a") as tmp_p:
for line in f:
if "//" not in line:
tmp_p.write(line)
os.system('npm install')
os.remove("package.json")
os.rename("package_M.json", "package.json")
I know it something like "Hacking" but it works for me :)
Hope it will help !
I did not understand your title, why would some dependencies would fail to get installed to package.json. The only explanation would be forgotten --save flag upon npm i.
Moving onwards,
Is there a optional file format for package.json to define our dependencies?
No.
If not, how can we manage to create a package.json with comments?
See the original question that this question duplicates: How do I add comments to package.json for npm install? there are some recipes there. Personally, I don't want to put comments in package.jsons, but I do use comments in my JSON's. I simply add dummy fields like "widt__comment___(value_below_is_capped_to_660_||_false_will_be_set_to_660_too)": false,. I omit the last letter and it appears on top when JSONs are sorted (next field would be width, so its comment starts with widt_).
why node/NPM forces developers NOT to document, by choosing a fileformat which makes it impossible to document?
package.json will have to be reliably parsed and rendered back, what limits the possible formats' choices. JSON is very reliable, old format, with very strict, known rules on its parsing and rendering. JSON is also covered by standards RFC 7159 and ECMA-404. TOML is not covered by any. YAML is not covered by any standards either. By the way, TOML is still on v0.x which is not even considered stable as per Semver.
Many resources on the internet (including here) suggest using Meteor.startup to fix dependency issues caused by the order in which JS files load. However, nobody spells out exactly how this is accomplished.
Specifically, it seems like file order dependency is the reason I can't get my posts.coffee collection to recognize permissions defined in my permissions.coffee. I think this is happening because posts.coffee is in /lib/collections, whereas permissions.coffee is in /lib, and files in subdirectories get loaded first. (Incidentally, I would prefer /collections to be in the root directory, but I had to move it into /lib previously to solve a similar problem.)
Here is my posts.coffee:
#Posts = new Meteor.Collection('posts')
Posts.allow(
update: ownsDocument
remove: ownsDocument
)
Meteor.methods(
...
And here is my permissions.coffee:
#ownsDocument = (userId, doc)->
doc && doc.userId == userId
(This is all from the "Discover Meteor" book tutorial, by the way, around these commits, except in CoffeeScript.)
My question: Assuming my analysis of the problem is correct, how would you solve it using Meteor.startup? This answer is hard for me to interpret; one interpretation is that I should wrap Posts.allow(...) in Meteor.startup somehow, but that seems really clumsy. Maybe I'm wrong, but it seems like there should be one general/config file with all the necessary startup code, and specific controllers should remain ignorant of it.
BTW, I realize I could hack a solution by taking advantage of Meteor's default file load ordering rules (e.g. /lib first; subdirectories first; main.* last; alphabetically), but that's a really inelegant solution to what should be a simple problem. I don't want to have to append "a" in front of a filename or create spurious directories just to get it load before another file.
One last note: I'm using CoffeeScript, and I wonder if the way CS handles global scope has something to do with it. (E.g., instead of defining my Posts collection as a JS variable without the var keyword, in CS I have to define is as #Posts, which I believe makes it a property of the window.)
Yes, you do just that:
Meteor.startup ->
Posts.allow(
...
)
Basically, any piece of code that uses a variable defined in another file should be preceded by Meteor.startup ->, unless you are sure that the loading order is correct (the variable is in lib, for example).
Yes, the loading order is poorly chosen.
I highly suggest you consider working entirely out of smart packages. That's how Meteor itself is largely written.
I go into more detail here: http://www.matb33.me/2013/09/05/meteor-project-structure.html
Ok, my question's not as broad as it seems, to summarize 8 months effort on my part:
I create chunks of re-usable, extensible XHTML which degrades gracefully and is all kinds of awesome. Most of my code chunks are provided a Javascript interaction layer, and are styled with CSS. I set to work pulling my code chunks into Dreamweaver as 'Snippets' but they're unintelligent chunks of text. Also, once inserted, my beautiful code chunks get mangled by the non-techies who are the ones actually using Dreamweaver.
Also, because they're unintelligent snippets, I have a line of Javascript which configures the code chunks when initialised - see this post for further detail on my approach. But currently I have to replicate a single code chunk as many times as there are configuration options (so each 'snippet' may only differ from another of the same type by ONE config value). This is incredibly lame, it works, but its lame and time-consuming for me to re-deploy a bunch of snippets and hard for my team to remember all the variations.
So I have a series of requirements, to my mind, as the most likely things to solve in any system I put my chunks into:
The inserted code is not modified at insertion time, by the system
The code to be inserted needs to allow config options
I'd be overjoyed if, once inserted, the only editable parts are text nodes
Copy and pasting these whole objects
A clean interface from which to choose from my range of code chunks
It's a serious list of requirements I presume, much searching led me to Kompoze and its 'Smart widgets' which, according to a random post from 2004, suggests XUL files can be created and extensions can be made which sounds vaguely like what I want. The text editor itself was less prone to destruction, when compared to Dreamweaver.
So yeah, I've chased too many rabbits on this one, keen as for a solution whether Software+extension, or Webapp.
EDIT:
Btw, it did occur to me to investigate a highly customised TinyMCE instance, but I don't know feasible that is, and unless there's some sweet backend available, I'm stuck with local editing of files for now - not even on a web server...
To my mind the best answer to this question will solve most of the above, and provide some general workflow advice alongside the suggestion(s).
I would go with a solution based around the excellent markItUp! editor. It's very simple to extend it to cope with the requirements you have. You can add sophisticated logic, and it's nice and shiny.
I'd probably combine it with Jeditable for the inline node editing, and build the whole thing on top of Django, for ease and convenience. Completely customisable, surprisingly easy to work with, portable and cross-platform, and easy to set-up for off-line use. Oh, and all free and open-source.
What do you think of this approach:
<div class="thing">
<elements... />
<script type="text/javascript">
document.write('<span id="thing' + thingNo + '"></span>')
new Thing().init({ id:'thing'+thingNo; });
thingNo += 1;
</script>
</div>
Of course, you'll have to change Thing().init so that it would initialize the parent (instead of current) node.
Have you considered server-side includes where the directive is either a generated page or a shell command? E.g.:
<!--#include virtual="./activePage.aspx?withParam1=something¶m2=somethingelse" -->
or
<!--#exec cmd="shellCommand -withParams" -->
You can reuse the same page or command, and provide parameters specific to each usage in each XHTML page.
My project seems to be getting bigger and bigger and some of my classes are thousands of lines long. It's too hard to search through them every time I want to make changes.
I find JavaScript is not as easy to lay out cleanly as some other programming languages. So when the classes get to be a few thousand lines, I have troubles reading it.
I've tried splitting it into multiple files, but then you're breaking classes apart, which doesn't seem right. For example, if every method in a class uses a global variable, you would only be able to find the global variable in one of the files for that class.
Also, if I want to use the JavaScript code from 100 different .js files, I end up with something like this...
<script type="text/javascript" src="Scripts/classes/Node.js"></script>
<script type="text/javascript" src="Scripts/classes/Queue.js"></script>
<script type="text/javascript" src="Scripts/classes/DblyLinkedList.js"></script>
.... 97 more lines like this
Although, I figured there may be something where I can do...
<script type="text/javascript" src="Scripts/.../*.js"></script>
or something similar... is that right?
Anyone have any tips on managing code as it reaches its extremes?
Tips on cleaning up JavaScript code would also be helpful.
Breaking up JS into separate files has some major drawbacks, chiefly that you're forcing web browsers to make a separate request for each file.
Have you taken a look at leaving all of your files separated out, but making a single-file "bundle" for each project containing only the necessary files? This can be automated via a script.
This SitePoint article might help you get started: http://www.sitepoint.com/blogs/2007/04/10/faster-page-loads-bundle-your-css-and-javascript/
(a) keep your classes shorter [even
though that will mean yet more
files],
(b) keep them "full-text
indexed" for speed of search and
operation (not aware of any IDE
specifically supporting Javascript
this way, but strong editors like
Emacs, Vim, Eclipse, or TextMate sure
do),
(c) group them up hierarchically
so your pages can have just a few
<script> tags for "upper layer"
scripts each of which just pulls in
several of the "lower layer" ones.
Oh, and, of course, religiously keep everything under a good change control system (SVN, Mercurial, or the like), otherwise your life will be surely very very miserable:-(.
You might want to group related classes together into packages, where each package is a single file. Check out YSlow for best practices on performance.
Well, a good editor is always usefull, as it will give you shortcuts to all your functions defined in the files.
Second, make sure you're not looking at a wall of code. Indentation, spaces and newlines are a good help.
Be extremely strict in your indentation. 2 spaces is 2 spaces, always(or whatever amount you use)
if you put your { under a declaration, then always put it there, without exception)
Clear rules about how you want your text aligned will help a lot.
And I don't know about that last thing... I'm not sure browsers can work with that kind of wildcard.
<script type="text/javascript" src="Scripts/.../*.js"></script>
will not work, and besides, you end up with an interesting problem when splitting up dependent files, as you can't guarantee they will all be downloaded in the order you expected.
Unfortunately, your best bet is really a good IDE that can produce an outline for easy navigation. I use Eclipse with Spket and/or Aptana, but whatever makes it easier to manage is what you're looking for.
edit: one more quick note about splitting js into multiple files. Avoid it where possible. Each separate file means a separate http request. Reducing the number of requests required can make a massive difference in site performance.
AvatarKava's advice is sound. Work in separate files and concatenate them at build time. However, I would also recommend you take a look at your class structure. A class "thousands of lines long" doesn't sound too healthy. Are you sure you classes aren't taking on too much responsibility? Are there not tasks that can be shipped out to other single responsibility classes? This would help improve the clarity in your code far more than cunning ways of splitting files.
Same advice applies to most languages...
Avoid globals wherever possible. You can often get the desired behavior by wrapping a static variable, or using objects.
if (foo == undefined)
var foo
Use naming conventions where possible so you can track things down just by reading the variable or function names. Either that or get good with grep, or get an IDE with intellisense.
Split things into directories. Having 100 files in a directory called "classes" is not helpful. As an example, you may have a collections directory for queues, lists, trees, etc. If you've got a lot you may even have a tree subdir, or a list subdir, etc.
You can then also create a global include for that directory... simply a file called collections.js that includes all of the files in that directory. Of course you have to be careful about splitting things up well, since you don't want to be including files you'll never use.