Re:Check that your Node.js project is well written, secure a...
by robryk on Monday October 20, 2014 @07:45AM
(#8481613)
What is meant by checking that the project is "secure" is checking dependencies against known security issues. While this is useful, this is completely different from what is advertised (I've expected some sort of a heuristic security anti-pattern detector).
Re:Check that your Node.js project is well written, secure a...
by nailer on Monday October 20, 2014 @07:54AM
(#8481642)
> I don't want to create/edit a new make/grunt/gulp file or whatever hype dev use these days.
Make is from 1977, and is pretty rare for web developers. gulp was designed as a grunt replacement, anyone familiar with the former can learn the latter.
I love jslint, I love checking for insecure npm modules, and the other things this module provides seem good too, but having a build system doesn't preclude any of those.
Re:Check that your Node.js project is well written, secure a...
by nailer on Monday October 20, 2014 @10:02AM
(#8482144)
Yes, web developers are generally unfamiliar with shell interspersed with Make. Not wanting two additional languages for your project is an excellent reason to use a tool that matches the rest of your project.
Re:Check that your Node.js project is well written, secure a...
by colanderman on Monday October 20, 2014 @11:46AM
(#8482702)
Not wanting two additional languages for your project
is a very silly reason. A build system is a system and needs to be learnt, whether it's a library in JS or a domain-specific language.
(That a JS-based build system shares syntax with JS is not relevant, since the useful denotation is JS syntax->build script, not JS syntax->JS code (unless you're debugging the build system itself). I contend that the denotation JS syntax->build script is no easier, and is perhaps more difficult, to learn than the denotation build syntax->build script, as it is, by definition, confusingly similar to the syntax for JS code!)
Re:Check that your Node.js project is well written, secure a...
by nailer on Monday October 20, 2014 @06:14PM
(#8484829)
> I contend that the denotation JS syntax->build script is no easier, and is perhaps more difficult, to learn than the denotation build syntax->build script, as it is, by definition, confusingly similar to the syntax for JS code!)
Really? gulp build step dependencies look almost exactly like AMD dependencies.
Edit: my wife has also asked me to ask you "will it scale?"
Re:Check that your Node.js project is well written, secure a...
by colanderman on Monday October 20, 2014 @09:56PM
(#8485553)
I've never used (or even heard of) gulp or AMD (I'm guessing they're widely used outside of JS-only environments), but from your statement I infer that one must be implemented as a JS library, and one must be a DSL with JS-like syntax.
Are you implying that my parenthetical is invalid because the DSL has JS-like syntax? You must have missed where I said "no easier" and "perhaps more difficult". If the DSL's syntax is identical to that of the library's, then clearly the denotation of the library is no easier to understand than that of the DSL – they are identical.
Re:Check that your Node.js project is well written, secure a...
by davexunit on Monday October 20, 2014 @10:15AM
(#8482224)
Any developer should know how to write basic shell scripts to glue things together. Not taking advantage of the excellent pre-existing unix systems tools is a huge mistake.
Re:Check that your Node.js project is well written, secure a...
by tokenizerrr on Monday October 20, 2014 @10:52AM
(#8482388)
That becomes a problem if you also want to have your project to be buildable on Windows, and it seems silly to exclude one platform solely because your build process doesn't support it.
Re:Check that your Node.js project is well written, secure a...
by richmarr on Tuesday October 21, 2014 @06:21AM
(#8486697)
Your comment seems to imply judgement of web developers for not looking outside their community, but fragmentation seems part of the nature of the software community. Demographically speaking, web developers are more likely to be younger, have grown up with Windows, and to have not developed for a different platform. In that context it's not surprising there's lower than average familiarity with Make.
Re:Check that your Node.js project is well written, secure a...
by malandrew on Monday October 20, 2014 @02:35PM
(#8483735)
make isn't even that good a build system... any system that requires that you create your own "clean" step(s) is wrong IMHO. A good build system is aware of the intermediate and final artifacts produced and knows what artifacts need to be created when changes are made [0].
That being said, javascript build systems just repeat the mistakes made by make, instead of learning from those mistakes.
Re:Check that your Node.js project is well written, secure a...
by robotkilla on Monday October 20, 2014 @07:36AM
(#8481580)
Interesting library – I ran it on one of my projects which consists of JS compiled from literate coffeescript. The JS also has also been run through browserify and uglify.
My code is tested using mocha (albeit lightly), passes lint tests and seems to have no issues pre or post compiling, however when I run check-build I receive 28 errors and 25 warnings.
Here is a sample of check-build's output:
line 4 col 448 Line is too long.
line 4 col 22 Missing "use strict" statement.
line 4 col 80 Expected '===' and instead saw '=='.
line 4 col 99 Missing "use strict" statement.
line 4 col 109 Expected '{' and instead saw 'return'.
line 4 col 123 Missing "use strict" statement.
line 4 col 124 Missing "use strict" statement.
This seems to be directly related to using uglify – my guess is that I need to tweak the config file to fit my stack (I'm using the default example).
edit - I already changed the config to match my directory structure and am running check-build on the compiled JS.
Make is from 1977, and is pretty rare for web developers. gulp was designed as a grunt replacement, anyone familiar with the former can learn the latter.
I love jslint, I love checking for insecure npm modules, and the other things this module provides seem good too, but having a build system doesn't preclude any of those.
Because web developers seem to be unfamiliar with software that has solved their problems decades ago in languages that aren't JavaScript.
is a very silly reason. A build system is a system and needs to be learnt, whether it's a library in JS or a domain-specific language.
(That a JS-based build system shares syntax with JS is not relevant, since the useful denotation is JS syntax->build script, not JS syntax->JS code (unless you're debugging the build system itself). I contend that the denotation JS syntax->build script is no easier, and is perhaps more difficult, to learn than the denotation build syntax->build script, as it is, by definition, confusingly similar to the syntax for JS code!)
Really? gulp build step dependencies look almost exactly like AMD dependencies.
Edit: my wife has also asked me to ask you "will it scale?"
Are you implying that my parenthetical is invalid because the DSL has JS-like syntax? You must have missed where I said "no easier" and "perhaps more difficult". If the DSL's syntax is identical to that of the library's, then clearly the denotation of the library is no easier to understand than that of the DSL – they are identical.
Was your wife's question supposed to be funny?
They're used widely used in things with a front end.
> I infer that one must be implemented as a JS library, and one must be a DSL with JS-like syntax.
No, they're both JS libraries. See Google.
That being said, javascript build systems just repeat the mistakes made by make, instead of learning from those mistakes.
[0] http://gittup.org/tup/build_system_rules_and_algorithms.pdf
My code is tested using mocha (albeit lightly), passes lint tests and seems to have no issues pre or post compiling, however when I run check-build I receive 28 errors and 25 warnings.
Here is a sample of check-build's output:
This seems to be directly related to using uglify – my guess is that I need to tweak the config file to fit my stack (I'm using the default example).edit - I already changed the config to match my directory structure and am running check-build on the compiled JS.