Using only one webpack for multiple plugins - javascript

Currently I have a lot of plugins co-mounted on a web application. But each plugin uses a difference version of webpack.
** Problem: In the future, I want all plugins to use the same webpack version. So I had to go into each plugin to update the version for the webpack. If I have 100 plugins, this problem is really a nightmare.
** My opinion: I think I can create a package, that will be imported and exported only one version of webpack.
Then I will use that package for all the plugins. When I want to update the version of webpack, I only need to update the version in one place.
I've searched the internet a lot to do the above. But at the moment I'm not looking for a way to do it.
Note: I am using Javascript.
Please help me!!!

Related

Is it ok to refer to node_modules directly?

The project I'm currently working on (Java/JSP) currently uses no package manager to manage its JavaScript dependencies.
The used libraries are just committed under version control, and referred as such from the JSP pages...
I would like to evolve to a workflow were we would use a package manager (e.g. yarn), and later on eventually also webpack to further optimise the build.
I would like to do this in a phased approach. As I have little to none experience with such a frontend workflow, I have some questions:
Would it be weird to just start with defining the used libraries in a package.json file, and use yarn to manage to package?
yarn will then fetch the modules and store them in the node_modules folder.
Is it bad practice to refer to the scripts in that node_modules folder directly from within the JSP files?
Example
package.json:
"dependencies": {
"jquery": "^3.4.1"
}
app.jsp:
<script src="node_modules/jquery/dist/jquery.min.js"></script>
Yes, that's completely ok. It's the way we normally initialize frontend projects (probably sometimes, some higher-level script does it for us but still). Just run npm init.
Oh yes, that's quite bad. Most probably, it simply will not work. If you want to load something directly on a page, you need a cdn version.
To be honest, having a package.json is not that useful without a building tool like webpack, gulp or grunt.
UPD:
Regarding why loading things directly from node_modules might hurt:
A lot of modern JS packages (like, for instance, React) use modules that are not implemented yet in any browser or ES5+ syntax which is supported only by some browsers.
This way, you may load React directly but it will crash in any browser with something like import is not defined.
Basically, a lot of modern packages expect you to either have a building tool or use cdn version.
Honestly, I don't know how many packages let you seamlessly load things directly from node_modules.
So, in your particular situation, I'd say that if particular packages you use let you do so & are shipped with browser-compatible version, you can just go ahead & do it this way.
Nevertheless, I see it highly possible that sooner or later you will face a package that will not let you to include it this way (or worse: it will, but will crash some browsers that don't support latest JS features/introduce other nasty bugs in your app).
Hopefully, at this stage, you will already have the building tool configured.
Bonus:
Relatively recently some browsers started to support modules!
There are even tools like snowpack that do something particularly similar to what you are looking for.
Even though, you still need to be very careful with this. Direct inclusion of lodash.js, for instance, will generate 640 GETs (check out this article -> "Libraries" section).
NPM packages are meant to be run with Node, not in a browser. You would need to serve a browser-friendly version, using something like webpack or browserify.

How do I include external libraries using Webpack in a Wordpress theme

I've decided I want to use Webpack and Babel to develop my Wordpress theme because I want to support ES6 features and still have my website work on older browsers (IE11), as well as other benefits such as being able to import files so that I don't have to have all of my JS in one big script.js file (e.g. for themes that use WebGL).
It's my first time setting up and using Webpack, I'm pretty sure I have it all set up in the correct way because I followed a few tutorials to do it and it's all working great, but my main question is with using external libraries. I have a couple that I need to use (i.e. Chart.js, Flickity, Magnific Popup, etc...) installed via NPM. I have a main script.js file that contains my normal Javascript code and gets bundled into bundle.min.js which is the file that is enqueued with Wordpress.
What is the best way to use external libraries alongside my script.js file with webpack?
At the moment the best solution I came up with is to have my script.js file setup in the following way:
// Imports
import 'magnific-popup/dist/jquery.magnific-popup.min.js';
import 'flickity/dist/flickity.pkgd.min.js';
import 'chart.js/dist/Chart.bundle.min.js';
script.js code...
When I run npm run build it all works fine and babel and uglify js work their magic to minify and make the code work on old browsers, but for some reason I feel like there's a better way to do it because I couldn't find any info online about it.
Is that the best way to do it?
Basically, we don't need to minify/transpile external libraries using babel-loader in webpack (as they already support all browsers internally). For these files, you can use script-loader instead of babel-loader.
One alternative way of importing would be by adding these libraries using npm and importing them where ever required. By this approach, webpack includes these libraries where ever required instead of loading it every time which is unnecessary.

Find dead code in large Javascript Application [duplicate]

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.

(webpack) library version conflicts, npm vs bower

Getting started with webpack, and while not explicitly stated, a lot of examples and starter kits use NPM over Bower for managing their front-end libraries. Further, recent articles suggest we don't need Bower any more. Maybe I'm using the wrong workflow, but I don't see how NPM can fully replace Bower when you're using libraries with shared dependencies.
Consider a project that uses jQuery and two jquery plugins. The first requires 2.2.0 and the other requires 2.0.3.
When webpack creates the bundle, two versions of jquery exist!?! Yes, the DedupePlugin can be used to remove the duplicates, but I can't find any documentation regarding which version it keeps. Seems like it just keeps the first one it encounters. Therefore, if I want to force a specific version, I need to npm install jquery and add a resolve.alias.
On the other hand, with Bower, I know exactly which version is being bundled. And should a conflict arise, it tells me. I can investigate the conflict and specify the appropriate version.
What am I missing? How are you using Webpack with front-end libraries? What is your workflow?

Wordpress plugin dev w/ JS library dependencies? Best long term approach w/ source management?

What is the best approach to Wordpress plugin development when your plugin requires numerous javascript library dependencies?
My example: I'm developing a plugin which makes heavy use of the Backgrid.js library in the plugins administration area. Basic dependencies of Backgrid.js are Backbone.js and Underscore.js. Not a problem because Wordpress includes recent versions of both in recent versions.
The problem? In my Backgrid.js implementation I'm also having to use many of the available extensions, like backgrid-paginator to get pagination working. Many of the extensions are listed here: https://github.com/wyuenho/backgrid/wiki#extensions
My head scratcher is how to best manage this plugin long-term with my source control management. Because I did NOT want to go the long route of downloading each individual extension myself, I simply used Bower (http://bower.io/) within my plugin directory to quickly download these dependencies. This creates a /bower_components directory in my plugin folder where all these dependencies sit.
Now let me preface, I'm pretty new to using Bower. But I'm also pretty new to Wordpress development so I'm not completely up to speed with best practices for this platform. Only working on it due to a client necessitating it.
Of course now my Wordpress plugin is filled with loading scripts such as:
wp_enqueue_script('backgrid-paginator', CUSTOM_PLUGIN__PLUGIN_URL . 'bower_components/backgrid-paginator/backgrid-paginator.min.js', array( 'jquery','backbone','underscore','backgrid', 'backbone-pageable'));
wp_enqueue_style('backgrid-paginator-css', CUSTOM_PLUGIN__PLUGIN_URL . 'bower_components/backgrid-paginator/backgrid-paginator.min.css');
What is the best approach in managing this plugin long term with source control? I'm a little bit of a novice with Bower and everything on Google only talks about using Bower with Wordpress theme development. Nothing speaks to using it with plugin development.
Thinking now, is the best approach to create a Bower bower.json in my plugin directory, which includes all these dependencies? I'll add this bower.json file then to my source control for the plugin, but a README installation requirement will be including that the plugin requires XXX dependencies and the easiest way is to just run: bower install in the plugin's directory to grab everything?
Is that the best approach? I'm trying to consider long term and make whoevers job it will be to take over responsibility for the plugin easier! :)
To my knowledge WordPress has no real standard for managing JavaScript and CSS dependencies outside of the enqueuing them in the right order.
Using Bower for managing the dependencies is definitely a good idea. It will keep your repo clean of vendor files and make it easy to update libraries later on.
If you want to make your life a little bit easier, you can also look into Grunt JS or Gulp JS which are build tools. You can use these to compress, uglify, etc all your JavaScript and CSS files into distributable items (e.g. all.min.js & all.min.css). This will make it easier to add/remove libraries.
Using these will also keep your enqueue statements cleaner.

Categories

Resources