npm: why publish a package for client side? - javascript

I am having difficulties in understanding why there is a trend/need to use npm to publish a package that is 100% client-side and has no dependencies. For example, a simple class that extends HTMLElement can not be used in Node and "installation" consist of adding script tag to HTML file, and yet there are thousands of packages. Is it only for bundling? Kindly excuse my ignorance, but sometimes it is important to know "why" before "how". Thank you in advance.
This is general question. I have checked similar questions but most of them are "how-to".

Bundling is an important advantage, not worthy of the "just" label.
It also provides versioning automation (one quick npm outdated and you can see if any of your dependencies have new versions out, and npm audit will alert you to security vulnerabilities).
NPM also has its own search engine so it provides discoverability.

Related

Accessing NPM public vs private package source code in node_modules

I'm pretty new to javascript development so apologize in advance if this seems obvious. I'm trying to build a private npm package that is not accessible to users.
However, I am able to see other npm package code that's supposedly not open-source by going into their respective node_modules subdirectory. So I'm wondering what the difference is between public and private npm packages since one can view the source code via node_modules folder either way.
Thanks for the help!
The privacy setting only affects wether a package can be published to a package registry or not and which people are able to access the package (e.g using restricted packages for custom company packages which are used in several projects). So "private" helps in preventing a package from being accidentally published and restricts the set of users who can access the package.
This is not a way to somehow obfuscate or hide your code from people whom you shared the package with!
While there are ways to achieve what you want to do, it's not as simple as you might think, as JS itself is not a compiled language and ca. (One way would be to write the code you want to hide in another, compiled language, e.g. C, and then call your C library via JS, basically using JS just as a wrapper)
TL;DR: If you grant users access to an NPM package they will be able to see the code of the package, end of the story. You can only decide who will be able to see/access the package by setting the privacy (public/private/restricted) of the package.

Difference between VSCode Live Server and Node Live Server

I'm getting started with JS so I've reached the point where I have to install a live server with npm. VSCode has a popular extension that many know of called Live Server(Ritwick Dey), my question is what is the difference between using the extension and installing the package with node? Are there any standout features that could aid in my development or are they pretty much the same? Thanks
Both will work in a similar way if you do not plan to use custom configurations and work alone on a single computer.
If you are working in a large team and want to have the same setup available for everyone, you should install the node module for the project and go with the 'Usage from node' section of the documentation.
Both options have great documentation on how to customize them. They differ in naming but for the most part both projects offer similar options.
For live-server, the npm package, your can use the online documentation to see the available ones.
https://www.npmjs.com/package/live-server
For the VsCode extension, you have a list of available configuration here.
https://github.com/ritwickdey/vscode-live-server/blob/HEAD/docs/settings.md
Before selecting one for you project, you should look at the available options and see if there is a feature that might be helpful for your project.

Share common typescript code across node projects

Assuming I have the following project structure:
webapps
ProjectA
SomeClass.ts
Package.json
ProjectB
SomeClass.ts
Package.json
Common
LoggingClass.ts
Package.json
The Common "LoggingClass" need to import a module from NPM. Let's assume that module is UUID (https://www.npmjs.com/package/uuid)
The problem, or the challenge is the following: We want to use and import the "LoggingClass" in both ProjectA and ProjectB.
Thing is, they can import the code from the common folder without a problem, but then the module "UUID" is not existent in those project because we did not specify so in their own respective Package.json.
I do not want to create actual node modules since my code needs to be checked into a git repository. (Some people recommend to develop directly into node_modules directory).
I would like to know what other fellow typescript developers do in the community to share their code when using npm. (If it was only typescript files it wouldn't be a problem, but because of the dependencies we have on npm.. it gets complicated).
Any thoughts would be greatly appreciated !
I do not want to create actual node modules since my code needs to be checked into a git repository.
A real npm module is actually a way to go IMHO. You don't have to store it specifically in npmjs.org (you can have an own npm repository).
Some people recommend to develop directly into node_modules directory.
This is actually the most inconvenient way I can imagine of. Probably, I'm missing something important, but I'd love to know their way of thinking.
There are things you will not be able to [easily] achieve with git-only based solution. For example, how would you checkout a specific version of the shared code, with keeping the rest of the code intact? It is relatively easy when you have only one directory where all the shared code lives. But if you have many (basically, directories-as-packages) then it gets cumbersome. And even figuring out their "versions" is tricky too -- you'd have to invent and follow a git tagging rule or some other way to annotate commits.
Anyways, what I am trying to say is that my answer is not exactly what you asked for; my answer is rather a suggestion to reassess you position regarding (not) packing code into an npm module -- which is de facto a standard in the JavaScript/TypeScript community for a reason.
I would like to know what other fellow typescript developers do in the community to share their code when using npm
Since your requirement I do not want to create actual node modules since my code needs to be checked into a git repository.
I would simply reorganize as
webapps
package.json
projectA
SomeClass.ts
projectB
SomeClass.ts
Package.json
common
LoggingClass.ts

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.

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

Categories

Resources