Develop Reference

'Modern' way of customizing Javascript libraries

Javascript dinosaur here. Back in the good old days, customizing a JS library was pretty easy. I'd download the non-minified version, put that sucker on the /js folder, do the changes necessary to the code and embed it on the html. Like this:
<script src="Sortable.js"></script>
Enter the marvelous world of modern javascript, a great advance where no project folders have less than 14mb. In this world, I don't download the file and put it on the /js folder, I install the package with 12 warnings and import it, and then a little program compiles it for me every time I need to test it. Takes 10x longer, but hey, my code is now compatible with the 0.0003% of users who use Internet Explorer 4. Wonderful. Anyway, this is the modern code:
import Sortable from 'sortablejs/modular/sortable.core.esm.js';
Sarcasm aside, I have a serious question: When customizing a library in a modern setup, of course, I won't change the final compiled version as it would be overwritten in a new build. I also wouldn't change the files sitting in node_modules folder, because these will be overwritten with every update. So what's the best way to do this?
Something tells me I have to fork the library, put the fork on npm and import the fork. I don't want to believe it. Is this really what I have to do to customize literally 2 lines of code?

If I had such a task, I would rather download the source code, do the changes, build it, and "install" it as a dependency using Local Path:
{
"name": "project",
"dependencies": {
"sortablejs" : "file:../path/to/sortablejs/bin"
}
}
But it's difficult to update the package with those changes. That's why you may consider using something like patch-package or using Yarn's yarn patch <package>, which lets you keep your changes separately from your package (in theory, I've never used it before).

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.

Is Yarn a wrapper over npm?

I'm aware of the benefits that Yarn brings about and what it does that npm doesn't. I do have some doubts however:
Does Yarn use npm under the hood for some of the other commands that retain the same behaviour as npm?
If no, is there a reason why they were re-implemented in yarn and are there downsides to this approach?

No, it is a rewrite.
Rather than continue building infrastructure around the npm client, we
decided to try looking at the problem more holistically. What if
instead we attempted to build a new client that addressed the core
issues we were experiencing? Sebastian McKenzie in our London office
started hacking on this idea and we quickly became excited about its
potential.
-- https://code.facebook.com/posts/1840075619545360
It offers the same API (without some shortcuts if you notice). This is (I am guessing) because the original interface was simple enough and to ensure adoption.
It is much faster, solves typical problems of npm (undeterministic deploys mainly). This can be only achieved with a top-down rewrite, they also changed how deps are installed (fetch, calculate, download, link) so the logic is different.
The downsides of this approach is that it requires a huge amount of work. Normally you would just PR over the main repo, but given they wanted a whole different thing and Facebook has the means, they decided going solo.
Another big downside is that its benefits won't be immediately available for all the npm older users, since it is not an upgrade and it does not come installed with node.

I had a look at Yarn's source code and found that there was custom code written for each command: https://github.com/yarnpkg/yarn/tree/master/src/cli/commands.
I guess the downside to this approach is that in future when npm adds new commands, the Yarn team would have to track the changes and manually implement them.

Load remote scripts with browserify

I really like using cdnjs to load up javascript on the client-side, it makes my project smaller and cleaner, and loads everything faster as well. I currently use require.js for module loading, which can load from cdnjs and shim traditional scripts to work with it easily. I've been looking more into browserify recently as an alternative, and while I did find browserify-shim, which can shim non-cjs modules much like require does, I'm curious if there is a way to load a script from a remote source with browserify, or if you have to install everything locally no matter what.
If the answer is that you would have to install everything locally through npm, this makes things a little weird. On one hand, you can add node_modules to the .gitignore file and not have to worry about keeping all the deps on version control if you are using a package.json, but on the other hand, you'd need to get the modules back in there on deploy, which means an additional post-deploy step that would run npm install and that node would need to be installed wherever you are deploying to, which also seems a little awkward to me for a static site especially.
Really, any ideas or discussion on this would be great : )

The way I think about it is this, you have three options: concat the JS files together locally (browserify) before deployment, load them in real-time (require.js), or a mix of both. To be fair, you can use require.js to concat your files with r.js too. For me at least, I like how browserify is designed to use the same syntax and mentality as npm modules. I think in the end the weirdness your experiencing doesn't really matter. If all the code is packaged together, you deploy, and there aren't any dependencies, seems like a win to me. Also, I think this is more in line with Java and similar compiled languages are doing, which is putting all the deps together in a deployable package. I know I mention Java but don't let that scare you because really we are all benefitting from the ideas of those around us even the languages we think we don't like. If I had to bet my money, I would bet on browserify since it's offering (what I consider) to be a more mature means of handling modules (organized by file based rather than syntax). The npm also gives us a great way to share our code so two thumbs up for them.

How do Bower and NPM couple together?

So to preface my question, I'm coming from a Java back-end developer perspective, where we use Maven to build. I have worked on testing on a server-side Node project we recently developed, but now I'm moving on to setting up testing on our front-end JavaScript client. I'm not very well-versed in front-end development and this is really my first foray into that.
All that being said, I'm thinking I'm going to use the following technology stack for our front-end testing: Eclipse IDE, Maven build process, Mocha testing framework, Chai assertion framework, Nock HTTP mocking framework, Sinon mocking/spying/stubbing framework, Rewire dependency injection framework. That all should be fine, and since that's the stack we use for our Node project, I would like to keep the front-end setup as similar as possible.
So, this is where my knowledge breaks down, though. I cannot seem to understand the difference in dependency management between our Node project and our front-end JavaScript project. I cannot see why I would not continue to use NPM, integrated into our Maven build, to handle dependency management and installation.
I see many people advocating Bower, but after looking at its page and docs, I still am not seeing what niche it fills that NPM would not. I am seeing a lot of adamant rejection of NPM insofar as browser dependency management goes; the main reasoning being that NPM is designed for server-side Node projects, and not for the front-end space. But who cares? Regardless of its initial design's intentions, if it does what I need it to do, where is the downside?
Please approach this "question" as if I am a complete newbie. I have realized as I've gone through this process and research, that I have very large dearths of knowledge in regards to the front-end side of things. With that being said, be as specific and thorough as possible in your answers, please. I would be happy to share project configuration and such, as needed, in order to help paint a picture of the space I'm in. Thanks for any feedback!

Bower and NPM do work differently.
NPM is very powerful and great at what it does. However, you won't find many client-side packages in there; most of them are there because they work in Node too. (For example, Underscore.JS and the JADE template engine.)
That's why you have Bower, which has the majority of the client-side packages. It has many jQuery plugins, templating engines, CSS frameworks, etc. Don't expect to find such packages in NPM.
You can work fine with both. I do so. :)

Traditionally, many web development projects combined npm and Bower. npm was used to manage back-end dependencies, while Bower was used for front-end dependencies. In fact, you needed to use npm in order to install Bower in the first place.
Although Bower’s advantages were compelling, they are now provided by other tools, namely npm, Yarn and webpack. While the open source project is still maintained, its creators decided to deprecate it, and advise how to migrate to other solutions—namely Yarn and webpack.
more explanation