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.
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
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!
I'm using jsdoc3 for my project and everything compiles nicely.
But this I've been fiddling with for the last 2 days and I give up :(
When using the most basic call from MacOsX Terminal to run jsdoc I ALWAYS get the full path of my source file within the generated documentation.
Example:
./jsdoc ../projectname/js/jsfile.js
In the generated index file I can see a h1 with "index" and below it a h2 with the full path to the js file:
/Users/username/projects/path/projectname/js/jsfile.js
I don't like that it shows my complete local path...
After reading up I thought it would be relative to where I run jsdoc from.
But all this has the same exact result:
cd /Users/username/projects/path/projectname
../jsdoc-master/jsdoc js/jsfile.js
as well as
cd /Users/username/projects/path/projectname/js
../../jsdoc-master/jsdoc jsfile.js
The problem is, that this path is also used with the line number references and on the sourcecode page. And it's really not nice that my internal path is displayed...
The output I would want is projectname/js/jsfile.js or at least just jsfile.js, but I can not for the life of me get this to work.
I hope someone can tell me what I'm doing wrong.
regards,
Jan
#Louis helped me figure out it was a problem with the alpha version.
3.2.2 did not export the full path to the docs.
Unfortunately it had other problems, like the lacking of support for unordered lists.
So I decided to stick with 3.3.0 and make a shell script correcting the wrong output of jsdoc afterwards.
Contents of the shell file:
./jsdoc-master/jsdoc ./projectname/js/jsfile.js
ABSPATH=$(cd "$(dirname "$0")"; pwd)
perl -pi -e "s?$ABSPATH/projectname/js/??g" ./out/*.html
So this basically deletes the full path from the generated html files.
It's a bit dirty, but it works...
regards,
Jan
What's the best way to disable JavaScript minification in CodeKit? All those *-ck.js files it creates are making a mess of our repository's submodules.
Note that adding a rule to .gitignore doesn't work because its rules aren't inherited by submodules.
In CodeKit Preferences select Languages / JavaScript to edit the default settings for JavaScript handling. (These can be overridden for each file in a project.)
Change the setting for the second processing step (labelled "Then:") from "Concatenate + minifiy" to "Concatenate imported files". For any script file already in the project check whether it already has individual settings which still differ from this new default.
In this case, "*-ck.js"-files should only be created in case a source file imports another for concatenation but not for ordinary script files.
Alternatively you might specify a different output path for the generated ck-Files in CodeKit Preferences / JavaScript / Output Paths in order not to let the generated files clutter the source directory.
I believe the menu has been updated, but the answer from immo still stands. Under Javascript Language settings you can click a dropdown for output style and change it from minified to non-minified.
One workaround is to set the output path to something like codekit-ignore in Preferences > JavaScript > Output Paths, relative to the project's root folder.
Then add /codekit-ignore to .gitignore.
Easy to cleanup and feels better than find . -iregex '.*-ck\.js' -delete.
In the preferences see 'Skipped Items' under 'General' and add *.js to the list.
There are several ways to stop javascript minification in Code Kit but the easiest and simplest way to do so is simple to navigate to the javascript file you wish not to minify in the file view, and configure your Javascript Options to the right hand side.
This method provides benefits such as JSHint & JSLint without the minification and can be configured on a site by site, file by file basis giving you greater control.
Let me know if you have any further issues, i'd be happy to help.
I'm using jslint4java in eclipse. Unfortunately I have a few huge dictionary files that never change but every time when the workspace is built, linting those files takes ages.
Is it possible to exclude specific files from jslint4java and how can this be configured?
In the version of the jslint4java Eclipse plug-in that I have (1.0.1.201207042009) there is an "Exclude files that match these patterns from JSLint:" field in the jslint4java preferences; I believe this is exactly what you are looking for.
It's below the "Make JSLint Laxer" list, on the right; if you have a long list of predefined global variables (as I do) you may have to scroll to see it.
When you enter an exclusion pattern as mentioned above you need to disable and re-enable jslint on the project for it to take effect. Cost me an hour...
Another note on excluding files using that pattern option. In my case I wanted to exclude every file that ended in .min.js. So, naturally I assumed the pattern would be *.min.js.
WRONG!
The pattern was just .min.js