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.
Related
I have been setting up my development environment for my Laravel/AngularJS project. My IDE is JetBrains PhpStorm. I am wondering what are the best practices for configuring the IDE to deal with the node_modules (or bower_components or vendor for my PHP) folder, so that:
It is not included in the code inspection as far as the modules' internal code is concerned.
It is included in the code inspection as far as references in my own code to the modules is concerned.
It is included in Autocomplete or Code Navigation (Ctrl+click on methods)
To make it more clear: I want to be able to Ctrl+click on methods of my node modules and be redirected to the source code of these modules. I also want to be warned if I write a node module method wrong, or if it does not exist. Also autocomplete a method, when I press Ctrl+Space. But I don't want the internal code of my node modules to be included in code inspection, because it takes a lot of time to inspect all the modules, and they are supposed to be ok, so I don't need to inspect them.
I already tried two solutions:
Marking the folders as excluded: This does not work because the folders are totally excluded from the project and redirection and inspection does not work at all
Creating a specific Scope (in PhpStorm Settings), that includes all files except the node_modules folder, to use when I manually run Code Inspection: It is impossible to exclude the node_modules folder, because my IDE recognizes it as a module "I think" (it has [webapp] next to it in the Project explorer). I could however exclude bower_components and vendor.
Regardless my tries, what is the best way to deal with it?
As it's mentioned in help, PhpStorm auto-excludes node_modules folder from indexing for better performance, adding the direct dependencies listed in package.json to javascript libraries for completion, etc. So the best way to handle node_modules is relying on the IDE default procedures
I am working on a project that is hosted as a monorepo. For simplification purposes let's say that inside there are three self-explanatory packages: server, a webapp client and library. The directory structure would be something like the following:
the-project
packages
server
src
webapp
src
library
src
All packages employ flow type notation, use a few >ES5 features and, for this reason, go through babel transpilation. The key difference is that transpilation of the webapp package is done via webpack, whereas server employs a gulp task that triggers script transpilation through the gulp-babel package. library is transpiled automatically when web is built.
Now, the problem I have is that for server to build, babel requires library to be built first and its package.json to specify its (built) main JS source file so its transpiled artifacts can be included. As you can imagine, this would quickly become problematic if the project were to contain multiple libraries that are actively being developed (which it does), as all would require building, including any dependent packages (like server in this simple case).
As an attempt to overcome this annoyance, I initially thought of using webpack to build the server, which would take care of including whatever dependencies it requires into a bundle, but I ran into issues as apparently webpack is not meant to be used on node JS applications.
What strategies are available for building a node JS application requiring Babel transpilation, such that the application's source files as well as any dependencies are built transparently and contained in a single output directory?
Annex A
Simplified gulp task for transpilation of scripts, as employed by server.
return gulp
.src([`src/**/*.js`], { allowEmpty: true })
.pipe(babel({ sourceMap: true }))
.pipe(gulp.dest('dist'));
As can be seen above, only server's own source files are included in the task. If src were to be changed to also include library, the task would emit the dependencies' artifacts in server's own output directory and any require('library') statements within would attempt to locate the built artifacts in packages/library and not packages/server/dist, thus resulting in import failures.
First of all, I am not sure what your server is doing. If it is doing a database connection or some calculations then I would not recommend it to be built by webpack. Whereas If your server is just doing Server-Side Rendering and making some API calls to other servers then I would recommend it to be bundled using webpack.
A lot of projects follow this philosophy. For example, you can take a look at something similar, I have done in one of my personal projects [Blubus]. Specifically, you might be interested in webpack-server-config. And also you can take a look at how big projects like spectrum does it.
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.
I have the same problem that has already been documented on GitHub here. ui-tinymce references a number of dependencies which cannot be reached in my application.
GET http://localhost:8080/jspm_packages/github/tinymce/tinymce-dist#4.3.12/themes/modern/theme.min.js # angular.js:6084
tinymce.js:9426 Failed to load: /jspm_packages/github/tinymce/tinymce-dist#4.3.12/themes/modern/theme.min.js
I am able to use the workaround suggested in the github issue above, which changes the baseURL. This works fine in my development environment. However, when I run jspm bundle-sfx it does not pick up these dependencies and I am left in the same situation without templates or plugins.
What is the best way to address this? Can angular-ui-tinymce be broken down so that the dependent files are available in separate packages? Or should I just use gulp to get around this problem?
I tried using Gulp to concatenate the missing files, however this will not work because by default tinymce still expects the files to be at the relative locations which it uses in its own internal file structure.
I still think it would be helpful for Tinymce to provide separate packages for the most common themes, however I admit that there are a lot of themes and plugins so this would be a fair amount of work.
In the end the simplest thing to was to copy the theme and plugin files into the "correct" relative directories within my own source code. This way I can change the relative baseURL for tinymce and it will be correct when I run it in production as well as development environments.
This way I can run jspm bundle-sfx and it will bundle these files along with everything else. However you may have to import the files explicitly if you do not serve the area statically in your application. For example:
import 'sysadmin/app/tinymce/themes/modern/theme';
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