Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Currently, whenever I want to use a module in node.js standard library that is not part of the global objects e.g. readFileSync(), I require/import the module which that functionality belongs to, in this example, that's the fs module. A list of the global objects is here for reference: (https://nodejs.org/api/globals.html).
Is there a way to require/import all the node.js standard library, i.e. to have all of the node.js standard library available throughout my program?
No, you can't require all node modules at once. There are tens of thousands of possible modules, some built-into node.js and some available only if you install them into your project. In the interest of modularity, you import into each module the modules that you need inside that module. This is purposely done this way to make modules be modular so that they declare exactly what they need to import and only what they need to import.
This is a bit different way of thinking than some other environments, but once you get used to it, it works quite well and makes code reuse a lot cleaner and easier. The start of each module file should import that external modules that you need to use within that module.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This sounds really stupid to me, but I don't really have an answer for this.
What's the point of using ES6 modules or CommonJS (in browsers using browserifiy), if you can just connect multiple js files to the html via the script tag so they act as modules (sharing the same scope)?
In decent sized web applications, you have to take in count that more than one developer is working on the project, so separation of concerns is one of the key elements to develop a maintainable application, lets pains the next fake scenario:
You have a file within your web application called library.js.
ES2015 module syntax
export function calculatesquareArea(object) {
// code that calculates area
}
export function calculateVolume(object){
// code that calculates volume
}
And now we import this module into our code by doing something like this:
import { calculatesquareArea } from 'library'
// We log the output of the execution of calculatesquareArea
console.log( calculateSquareArea(object))
You can notice right away that in my module I have 2 functions but I've decided to only import one because at that time I've only needed to use that. Maybe this is a silly example but you can picture code reuse with the modularity nature of CommonJS or ES6 modules.
There is a more elaborate article on the key differences between CommonJS and ES2015 modules here
Hope this helped a little bit.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
This is more of a question regarding the architecture of an application, let's say you have a module something.js with some kind of special configuration constants mind you that these constants are hardcoded they are not imported from env or some file.
Would it be better to put everything related to this module as a global constant or is it better to import all configuration constants from config.js for example.
I'm interested in knowing the pros and cons from an architecture point of view.
If it's something high-level or broad, like a debug option that turns on debug output across your app, I would be inclined to put it in a common config file. On the other hand, if it's something specific or narrowly scoped, like how many characters a particular piece of text can be before it's truncated, I would be inclined to keep it in the only file that references it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know a lot of people use the word "compile" quite loosely and interchangeably but I was hoping someone could explain to me like I'm 5 if it's technically incorrect to call a JS module bundler (eg. Webpack) a compiler or a build tool? I often hear things like "you have to compile your JS in order to update your bundle".
Thanks in advance.
It's definitely a build tool, and one which can be automated. One of the main use cases is to bundle various javascript sources into one or several bundle(s) of javascript, which is generally referred to as 'transpiling'. Transpiling basically means the output is the same language as the input, ie javascript in javascript out. Compiling is generally the act of turning source code into machine language, or IL. Webpack can of course also bundle other things, which is why on their own webpage they refer to it as a bundler.
In a colloquial sense, people often mean 'compile' to be the same as 'build', in the sense that you run your build tool.
Webpack it is a build tool.
Maybe you heard some like "some node package could not compiled for your OS" like
node-sass module. This module compliled from source code
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Angular 2 looks better and simpler than Angular, however, I have a problem using NPM - it is not allowed at my work. But the bigger question I have is why do we need NPM at all?
I have used Angular with CDN versions, which was always claimed to be better than a local version (better caching) so, what is the advantage of using NPM manager vs CDN references if any? Why grow a local size of a project?
Today I see WEB development uses NPM everywhere.
I want to understand WHY all of the sudden WEB development started to move toward local resources vs common, online resources.
I am looking for convincing explanations, good articles/blogs pointing to why chose one vs another.
One of the benefits of Angular is that the framework is structured in a way that allows you to tailor the application bundle to your specific application needs.
This is not possible with a one size fits all iife download from a CDN
If you look at the Angular npm packages you will see that they consists of a number of smaller modules that make up the framework.
Using a technique called "Tree shaking" your bundler can run static analysis on your code dependencies and create a bundle that only includes referenced modules. This can drastically reduce the bundle size.
Here is a some more info about Tree Shaking:
http://www.syntaxsuccess.com/viewarticle/tree-shaking-in-javascript
Mainly because a modern web app will use some kind of dependency or module loader, like requireJS or (in case of Angular2) SystemJS, or commonJS, and CDN sources make that more complicated, since it requires a new resource http connection to get your source asset, and from a different domain (crossserver scripting issues)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Am I missing something out of not using browserify?
I am a big fan of Yeoman, especially because of how they do things. By that I mean, their opinionated approach using, among other things, usemin and wiredep to handle client-side dependencies, transforms, and bundling.
However, I keep bumping into this one library, Browserify. Also as of late there's been a lot of hype regarding another, Webpack.
Having just read the latest npm blog post about the future of npm and module packaging in focus of the browser, all of this lead me to question myself - am I missing something here not using browserify?
Is it fair comparing something like browserify, webpack or inject to something like usemin with wiredep? If so are there any clear benefits to using any?
Its pretty fair to compare these. They all do multiple things with a lot of overlap between tools.
The main difference is if you are using some type of standard module loader like ES6 modules, requireJS etc.
usemin + wiredep works the old school way, you point it to all the files you want to minify etc and it will smash them all up and wire that up to the script tag.
The others read your imports/require and will track down the code they are using and smash that together. There are a ton of ways to optimize what code is actually imported compared to usemin. (dead code optimization, lazy loading)
In short if you are using a module loader like require then yes you are missing out.