I want to start formally documenting my NodeJS project written in CoffeeScript. After investigating most of the documentation options I've decided to (attempt to) go with JSDoc.
Given that I've installed this globally with NodeJS, is there any way I can get JSDoc to recognize my .coffee files the way Mocha and Node itself do? (Both support compiler flags, eliminating the need for build tools like Grunt or Gulp)
Since JSDoc uses espree(JavaScript AST parser), you can't do that. But some alternatives like Codo or Docco exist.
Related
I'm just starting to learn Angular, I installed in my Ubuntu Linux:
Angular CLI: 7.1.4. and
Node: 10.14.2.
My question is, why one project is too large? I mean a simple "helloworld" is 334MB, I don't know why, Is it possible resize it? or delete any folder that is unnecessary? Or Is there something wrong with my installation? (how can I detect that?)
The bigger folder is node_modules, and when I create my projects, generates a lot of folders.
I was reading about "angular lazy loading", but I'm new.. It is not totally clear for me.
this is the folder spaces:
Please... I hope somebody can help me...
best regards
You might be using big bundles which are not needed, so you can break them up:
https://medium.com/#julienetienne/javascript-bundles-are-too-big-break-up-the-libraries-3be87d5ef487
In modern JavaScript, projects require modules that themselves require modules that require modules... resulting in node_modules directory with hundreds of dependencies. A 100Kb library might be included because someone needed one function from it. JavaScript is not compiled, so all that source tends to be rather big. This is an unfortunate, but unavoidable truth; your Angular project directories will be big, and there's nothing you can do about it. It is perfectly normal.
The good part: modern JavaScript deployment typically includes packing up those libraries with Webpack or Parcel or similar code bundlers. Most of them implement "tree shaking", which analyses the code to find only the functions that are potentially utilised starting from the entry point, and only bundle those, ignoring the rest. This means that 100Kb library whose one function is used is transformed into just that one function in the final distribution bundle.
Not all of the bundlers are equally good at it at this point. For example, Webpack cannot tree-shake the CommonJS modules, only ES6 ones.
You can remove node_modules folder when you are not going to use the app.
And, when you need work on the application, you can re-generate node_modules using the command: npm install
Those are just node-modules, they are needed for building the project, but not necessarily everything inside of them will be deployed to production. As Amadan said, there is a process of tree-shaking (filtering only used modules) and also in production you use the minified version of the same JS code (where for example whitespace is missing and variable-names are shortened), among other optimizations. A production-optimized Angular project should not be more than a 100KB for a hello-world application.
In the provided image I see packages like
selenium-webdriver
protractor
Those belong to dev-dependencies (see your package.json file) because they are used for testing. When building for production, no code from dev-dependencies should be included. The typescript package (which is nr.2 in size in your screenshot) will also not be present in production because types like string are only used for writing Typescript code, but the browser receives Javascript, which it is compiled to.
Some Node.js projects use things like Babel, Gulp, Webpack. Other Node.js projects don't use such things. Do I have to use them in my Node.js projects and why? Perhaps you know different cases when I should take one of these decision?
No, you do not need.
Webpack is a bundler, it is intended to help packing up multiple files into one single file. Throughout this process you can transpile the code to apply modifications on it, eg: convert from es6 to es5 (if needed).
To transpile your code from es6 to es5, you are going to need babel, where you can do a lot of stuff with that.
Gulp is a task runner/manager, not used that often since most of people use webpack nowadays. But still useful for a bunch of stuff.
If you are going to develop pure node.js projects, you don't have to worry about this. For web you should be aware of all of these tools.
I've found Babel, Gulp, Webpack can be used in Node.js projects with cases:
you need to minimize production code.
you'd like to use all ES6+ features (like 'export' and 'import', decorators).
you want to use JavaScript extensions like TypeScript.
If for some reason your project contains .js files are intended to run in different environments (Node.js, casperjs, browsers), you would like to use ES6+ inside all .js files.
Can someone give me some advice or links for discussion on whether I should bundle JS for backend?
I tried to Google with this title (and similar words) and I can't get any useful links.
Just want to know, say I am using latest Node.JS (es6-ready), should I bundle/compile the JS? If not, how am I suppose to use typescript/flow?
Thank you.
I feel like you are asking two different questions. I'll try to answer both.
How can I just run TypeScript code?
This is the one your question's title seems to ask ("How to use typescript/flow in nodejs without compiling it"). For this, you can use the ts-node package on npm. But it's usually not a good idea to use ts-node over just compiling when running in production because it tends not to be as fast.
How should TypeScript code get distributed to be run?
Any TypeScript code will need to get compiled from .ts files to .js files to eventually be run. Basically something like the same thing applies to Flow code.
If you plan to distribute a package written in TypeScript, you should be publishing the .js and .d.ts files together. This is so that
Your package consumers don't have to recompile your package. (they already get .js files.
Your non-TypeScript consumers don't need to install TypeScript to use your package. (they already have runnable .js files)
Your TypeScript consumers can get good type safety and completions. (they get your .d.ts files)
For more information, see the TypeScript documentation on Publishing Declaration Files.
So the thing is I went through the internet and checked for available linters. Mostly all the the LESS linters available provide a command line interface or a plugin for grunt or gulp. What I really want is a simple Node Plugin which is configurable and usable with NODEJS through Code and not through CLI.
Also due to unavailability of the tags such as LESSLINT and SCSSLINT could not add those tags to the questions.
Is there any node plugin available to do this?
If not, How can I use CLI through NodeJS and also get the callbacks?
I need the callbacks since that's the most powerful feature of NodeJS and besides my code is dependent on the callbacks..
P.S.: I do not need any code, all I need is directions.
Thanks for the support
A Node port of scss-lint was recently released, you can get it here: https://github.com/FWeinb/scsslint
It can be used either in Grunt or just as a normal Node module.
LESS has built-in linting, but it doesn't seem to be accessible through Node. You can use spawn or exec and the LESS CLI with the --lint flag. See the LESS docs here: http://lesscss.org/usage/#command-line-usage-options
I'm a Node n00b starting a couple web app projects using Express, and I've got some common client-side libraries I'd like to share between the two projects. This seems like a very common problem, so there must be several solutions available already.
I come from a java background, and in java, I'd create a separate "common" project and "overlay" common WAR over my project during packaging. This would also allow for r.js optimization during the build process.
My best guess in Node is that I need to create a private NPM module, and map those common files into express via a use() middleware plugin. Is that right?
How, then, can I package both my common and project specific javascript into a minified file using r.js?
Or is source control the answer? Checking out my "common" repository inside each project?
Any help would be most appreciated. Thanks.
This seems like a very common problem, so there must be several solutions available already.
Good news: Yes, this is a common problem. Yes, there are several "solutions".
Bad News: All of the "solutions" are at least partially terrible.
Here's my advice:
1) Individual .js files should be coded as CommonJS modules
2) Groups of related .js files should be made into npm packages
3A) Use them in node via the regular node.js/CommonJS require function and use browserify to use them in the browser
3B) OR use a built tool like grunt to wrap commonjs into AMD format for use with requireJS in the browser
3C) OR consider something like component.io components