I was thinking that what if we bundle all the classes we have into a single file but don't use babel to polyfill it to ES5 .
and if the browser didn't support rs6 use babel in the browser or load the polly filled bundle and add the dependencies manually.
i don't know if it's a good idea to do that , but i think babel adds a huge size to my bundle . i have 300kb of code (not minified) with almost no dependencies (only react and router).but after bundling and minifing i get a huge file with 1mb of size.maybe im doing something wrong here.i also used preact instead of react , but it didn't help me that much.
thanks in advance.
Babel shouldn't end up in your bundle. babel-polyfill might, if you need some features it provides, and it can be fairly large.
What toolchain are you using? If you use Webpack, you can analyze the bundle's size with e.g. webpack-xray (disclaimer: my project).
Related
I am running on a huge project with thousands of .js files that are written in es5, and for many reasons and benefits of TS, we've decided to start migrating to TS, after a couple of days and many pieces of research, I am going to elaborate a couple of points:
To start migrating from es5 to ts we can start either by two ways:
First way:
1- Installing ts, creating tsconfig with allowJS set to true then start changing the extension of files to .ts and everything will work by default
2- As we want to migrate gradually we don't want at once to replace the global scripts to native modules, in other words, we don't want immediately to type import and export, but instead we want to keep the old way global scripts and use /// <reference path=""> to load dependencies
3- after previous step we can gradually start turning the files into native modules esm
Second way:
1- As I've read about UMD it will work on both borwser(client) and server, which means support all type of modules AMD, CommonJS, SystemJS and Native ES modules
2- after re-writing the scripts in UMD fashion, we can gradually start moving our scripts to ESM
last but not least, and regarding the intelligence we'll start writing .d.ts files accordingly or we can rely on ts-loader to generate the files
lastly, we either go with ts-loader or babel but we are not sure if there are couple of limitations for each of which
Any idea is really appreciated on what is the best way to start migrating
Maybe this tool can help you:
https://github.com/airbnb/ts-migrate
ts-migrate is a tool for helping migrate code to TypeScript. It takes a JavaScript, or a partial TypeScript, project in and gives a compiling TypeScript project out.
ts-migrate is intended to accelerate the TypeScript migration process. The resulting code will pass the build, but a followup is required to improve type safety.
If possible, start fresh and write migration script which does copy/paste task of code. In which Project setup will be error free in term of compile/build/run/lint. So even in future there won't be any issue you just need to add modules. You can migrate module by module.
Now if you are migrating to TS means not just by extension or package type, because it won't benefit more, you will need to change in code like types, interfaces, configs etc.
So starting a fresh project and then converting code to TS and then gradually moving should be better.
I would suggest you should write new modules in typescript and slowly convert existing files and modules to typescript. But keep the output in js only. Convert each ts file into js, For e.g, if you have a module Utils create two folders inside this ts and js. Write a build script which will convert ts to js and move inside the js folder. This way you will be converting all files into ts. For import/export you can start it for the new module. I have done the same in one project.
Regards,
omi
I appreciate all the answers but for my case it is so complicated because ts modules will affect the scope, what I found useful is using what so-called shimmer modules in webpack which allows a feature called imports-loader which I can use to manipulate the scope of js, hence nothing is broken, then I can move file by file to start migrating
In order to refactor a client-side project, i'm looking for a safe way to find (and delete) unused code.
What tools do you use to find unused/dead code in large react projects? Our product has been in development for some years, and it is getting very hard to manually detect code that is no longer in use. We do however try to delete as much unused code as possible.
Suggestions for general strategies/techniques (other than specific tools) are also appreciated.
Thank you
Solution:
For node projects, run the following command in your project root:
npx unimported
If you're using flow type annotations, you need to add the --flow flag:
npx unimported --flow
Source & docs: https://github.com/smeijer/unimported
Outcome:
Background
Just like the other answers, I've tried a lot of different libraries but never had real success.
I needed to find entire files that aren't being used. Not just functions or variables. For that, I already have my linter.
I've tried deadfile, unrequired, trucker, but all without success.
After searching for over a year, there was one thing left to do. Write something myself.
unimported starts at your entry point, and follows all your import/require statements. All code files that exist in your source folder, that aren't imported, are being reported.
Note, at this moment it only scans for source files. Not for images or other assets. As those are often "imported" in other ways (through tags or via css).
Also, it will have false positives. For example; sometimes we write scripts that are meant to simplify our development process, such as build steps. Those aren't directly imported.
Also, sometimes we install peer dependencies and our code doesn't directly import those. Those will be reported.
But for me, unimported is already very useful. I've removed a dozen of files from my projects. So it's definitely worth a shot.
If you have any troubles with it, please let me know. Trough github issues, or contact me on twitter: https://twitter.com/meijer_s
Solution for Webpack: UnusedWebpackPlugin
I work on a big front-end React project (1100+ js files) and stumbled upon the same problem: how to find out which files are unused anymore?
I've tested the next tools so far:
findead
deadfile
unrequired
None of them really worked. One of the reason is that we use "not standard" imports. In additional to the regular relative paths in our imports we also use paths resolved by the webpack resolve feature which basically allows us to use neat import 'pages/something' rather than cumbersome import '../../../pages/something'.
UnusedWebpackPlugin
So here is the solution I've finally come across thanks to Liam O'Boyle (elyobo) #GitHub:
https://github.com/MatthieuLemoine/unused-webpack-plugin
It's a webpack plugin so it's gonna work only if your bundler is webpack.
I personaly find it good that you don't need to run it separately but instead it's built into your building process throwing warnings when something is not ok.
Our research topic: https://github.com/spencermountain/unrequired/issues/6
Libraries such as unrequired and deadcode only support legacy code.
In order to find the unused assets, to remove manually, you can use deadfile
library:https://m-izadmehr.github.io/deadfile/
Out of box support for ES5, ES6, React, Vue, ESM, CommonJs.
It supports import/require and even dynamic import.
It can simply find unused files, in any JS project.
Without any config, it supports ES6, React, JSX, and Vue files:
First of all, very good question, in large project coders usually try many lines of code test and at the end of result, hard to find the unused code.
There is two possible that must be work for you - i usually do whenever i need to remove and reduce the unused code into my project.
1st way WebStorm IDE:
If you're using the web-storm IDE for JS development or React JS / React Native or Vue js etc it's tell us and indicate us alote of mention with different color or red warning as unused code inside the editor
but it's not works in your particular scenario there is another way to remove the unused code .
2nd Way unrequired Library: (JSX is not supported)
The second way to remove the unused code inside the project is unrequired library you can visit here : unrequired github
another library called depcheck under NPM & github here
Just follow their appropriate method - how to use them you will fix this unused issue easily
Hopefully that helps you
I think the easiest solution for a create-react-app bootstrapped application is to use ESLint. Tried using various webpack plugins, but ran into out of memory issues with each plugin.
Use the no-unused-modules which is now a part of eslint-plugin-import.
After setting up eslint, installing eslint-plugin-import, add the following to the rules:
"rules: {
...otherRules,
"import/no-unused-modules": [1, {"unusedExports": true}]
}
My approach is an intensive use of ESlint and make it run both on IDE ad before every push.
It points out unused variables, methods, imports and so on.
Webpack (which has too nice plugins for dead code detection) take care about avoiding to bundle unimported code.
findead
With findead you can find all unused components in your project. Just install and run:
Install
npm i -g findead
Usage
findead /path/to/search
This question recalls me that react by default removes the deadcode from the src when you run the build command.
Notes:
you need to run build command only when you want to ship your app to production.
Due the fact, that ES6-modules (JavaScript-modules) are available for testing:
https://www.chromestatus.com/feature/5365692190687232
https://medium.com/dev-channel/es6-modules-in-chrome-canary-m60-ba588dfb8ab7
I wonder, how should I minify and prepare the project release-file? Earlier, I havde bundled all JavaScript-files into the single and minified file, except situations, where I have to load the JS-file dynamically via XHR or Fetch API.
As I understand, it's rather impossible to prepare a single-minified file with the ES6-modules right now or may be, I'm just misunderstanding some ways of work.
So, are the any ways to prepare my ES6-modules into single file and how I should prepare the modern JavaScript-project in 2017 year, where JavaScript-modules will be available?
I wonder, how should I minify and prepare the project release-file?
That is purpose of this action? Okay, minified files take fewer network traffic, and will be downloaded faster, but most NPM libraries provides minified dist-files already. And main question about bundling in one big file.
Why webpack do it? Of cource, due absence of support for ES-modules in browser by native, What's why webpack resolves import statements and round dependencies in synchronous manner*, and then substitute it to IIFE for scoping. And perform babel translation and polyfilling, yes.
But then native support of ES-modules is started, it's become un-useful. One of main goals when exposing your web-app to production, is minify traffic volume for your server, using CDN. Now you can do it in native way, so just import ES-modules from unpkg.org and be happy
*If not using HMR, of course, But it's not appropriate for production mode.
Live examples here: https://jakearchibald.com/2017/es-modules-in-browsers/
This blog explains how you would use the ES6 module syntax and yet still bundle your code into something that the browser will understand.
The blog explains that using SystemJs as an ES6 module polyfill and Babel along with Gulp will enable you to code you modules in ES6 yet sill be able to use it today.
https://www.barbarianmeetscoding.com/blog/2016/02/21/start-using-es6-es2015-in-your-project-with-babel-and-gulp/
Using this guide will help you write your code in ES6 while still having a normal workflow to building, minifying and bundling your code.
Keep in mind there are a lot of tools out there that will help you achieve this but I've followed this method many times and I can vouch for its validity.
Looking at the jQuery documentation on npm, I'm confused as to what I have to do to use it. I know that I can just include the script tag in my index.html to use it, but how does everything else work?
If I choose to not use the script tag, I understand that I can install with node and then import it with Babel into any file that I want to use jQuery in. But where does webpack come into play? I only have to use webpack's require if I'm not using Babel, correct? Is webpack's require an alternative to Babel's import?
It seems like either I can use Babel and Node.js or webpack and Node.js? I thought Babel and wepback serves separate purposes though, with Babel trans-compiling ECMAScript 6 to ECMAScript 5 and webpack bundling all your files into one. If I'm currently using webpack, Babel, and Node.js. What is the best way to include and use jQuery?
If you plan on working anywhere without an Internet connection, go ahead and npm install the minified version of jQuery into your modules.
Otherwise, I would use the CDN in the HTML file for easy global jQuery access. It doesn't really make a difference how you include it in your project in terms of webpack/babel methods; just be sure to stay consistent with how you import them. The only difference is that require is ECMAScript 5 and import is ECMAScript 6.
I have a question regarding following TypeScript plugin for SystemJS :
https://github.com/frankwallis/plugin-typescript/
Here is its description
A plugin for SystemJS which enables you to System.import TypeScript files directly. The files are compiled in the browser and compilation errors written to the console.
I wonder what would be the use cases of such plugin.
Why would developers import directly ts files and compile them in the browser instead of compiling them during development and import js files ?
Won't it reduce performance and load time to do it in browser ?
Is it supposed to be used only in development environment ?
plugin-typescript author here. In-browser compilation is strictly a development tool, in production you would use systemjs-builder (in combination with plugin-typescript) to create a single file containing all of the transpiled javascript.
Since the plugin was originally developed, a number of new workflows have become available when using typescript & systemjs (typescript single-file transpilation, vscode, systemjs hot-reloading, typescript system.register output, to name a few...) - Which one is right for you will depend on the size of your application, the platform/server you are using, and your own personal preferences.
No one in their right mind would compile/transpile in the browser for production; it's the equivalent of sending a turtle to get your mail because you don't like walking.
This is strictly a development tool for helping TypeScript devs avoid having to constantly compile after every change, with the added benefit of providing features like hot reloading.