I want to do unit testing with my Adobe JSX files using Jest.
However, all Jest tutorials have some package.json which I don't use, and they use modules and requires which aren't in ES3 javascript, etc.
Plus 'JSX' has been appropriated by React, so it's also probably going to think I'm doing React files and not Adobe ES3 files.
Is there some way to use Jest and not bother with any modules and packages? I just want to test some ancient-style ES3 code that's just javascript.
If JSX extension is going to muddle things up, is there a way to do this with a single JS file?
Eventually I got some help and it was stated to me that I should install the jest with its modules in the project's directory - my global installation won't do. And, sure enough once the installation went, it worked.
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.
Sorry if I'm missing some obvious thing, but I can't seem to understand why react (or react-dom) should be a dependency and not dev-dependency on most projects..
Usually the src is written in es6 and stored in /src or /client for example, and when someone want to build the project for prod he will create /build or /dist where the finalize bundle.js will seat (using webpack and such). from there (at prod) it simply a web server which serve regular js (the bundle) and html file.
Do I miss somthing?
I dont understand why will I want react on the prod (unless going for SSR of course)..
Thank you very much!
dependencies are required to run, devDependencies only to develop, e.g.: unit tests, Coffeescript to Javascript transpilation, minification, ...
React is a dependency because it is included in the final build.
In case of a React App, all your JSX is converted to a syntax similar to React.createElement and hence you would require your App to have React during run time as well. Similary methods like setState and lifecyle functions are all executed during run-time.
As a matter of fact react is a library that has exposed some methods and APIs to access and manipulate DOM.
Consider this similar to jquery or express where you add it in the production build because they are being used during run time.
When creating a react app, things like babel, webpack etc which are only used to create a bundle would be dev-dependencies as once the packaged bundle is generated it need not be generated during run time of application
I had the same question and found this article that explains it well.
To summarize, it shouldn't matter where you put the react dependencies since Webpack will bundle them into a self-contained file and the code will run fine in either case. However, separating development and production dependencies allows for a better communication to other developers for the purpose of these dependencies.
A dependency is something that is imported in the src/ or client/ module like you mentioned. The code that you run depends on it and hence is required in the production bundle.
If it were something like Babel it could be a devDependency because:
It is not imported in source code.
It is a transpiler and works on code in compile time
But that is not the case with React. Functions like setState or lifecycle hooks are being executed in run time, meaning the library has to be present during run time.
React could very well be listed as a peer dependency is some of the popuar libraries. This is because we assume that all projects that are going to use this library are going to have React installed. Like consider the case of react-bootstrap. It can only be run in react projects, so we include react as peer dependency reducing the overhead of installing it.
If you need a framework that would disappear in compile time, take a look at Svelte.
Are there any existing solutions for run-time bundling of ES6 modules?
I'm looking to simplify JavaScript code development in a MVC5 web app. We're having issues with large, unwieldy JS files, so I'm hoping to get a module loader system in place. So far, I'm not finding any existing bundle transformers for ES6 or another module loader format. I'd be fine with using TypeScript or nodejs require style. I prefer not to use require.js style, though.
Perhaps there's a good reason this solution doesn't exist already. Maybe the dependency resolution processing is too much for a run-time bundling solution. But, I figure it's worth a shot to ask.
Solutions Considered
Prebuilt Web Client
Ultimately, this is where I want to be, but I need a stop-gap solution for now. I know how to put together a build system for an HTML client using grunt/gulp/webpack. But I don't want to have to tell developers to run webpack -w or something similar during development. Nor do I want to tell them to rebuild a solution for every JS change. They should be able to modify the file, refresh the browser, and see the change.
Directory Structure
This is the route I'll probably end up going with. Basically, this JS codebase consists of jQuery widgets and plain JS (helpers/common functions). So, if I structure the code in this directory structure and include the js dir, it should get me most of the way there:
js (DIR)
app-start.js
helpers (DIR)
widgets (DIR)
Widgets should be fine. Helpers, I can see issues where one function/class depends on another. Though, since a function call should never start with a helper (only a widget), this should work fine, assuming no globals are used (or maybe one global like 'App').
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.