Can you publish an npm package for a frontend JavaScript file? - javascript

A client would like to use an npm package to access our JavaScript file's functions instead of adding a script tag to their html. Is this possible? The only resource I've come across for creating an npm package is for NodeJS files (https://docs.npmjs.com/creating-node-js-modules).

This is possible but you cannot import the npm package and have it work in the browser without some sort of bundling system like webpack.
Alternatively, which is a bad idea, would be to ship your dist folder with node_modules in it. This isn't recommended for a multitude of reasons, but it will work.

Following approach might be suitable for your client's requirement.
Create a NPM project using the javascript file you have
Publish it on client's Github account as a package.
Create a .npmrc file in root of your client's project.
Add your package in .npmrc file and in packages.json both.
Refer this doc for using a package with .npmrc file:
https://docs.github.com/en/packages/guides/configuring-npm-for-use-with-github-packages#installing-a-package).

Related

Properly linking to a javascript library installed with npm?

When I install a JS library with npm, say:
npm install chartjs
It places the required JS file in ./node_modules/chartjs/chart.js.
Since I want the file to be located in, say, ./public/js/chart.js, I could just copy and paste it there. But is there a proper way to do that, like linking directly to the file installed by npm ?
Thanks in advance for your help. (Yes I'm kind of new to JS...)
In general, if you are using npm to manage your dependencies then you would use a bundler (such as Rollup, Webpack, or Parcel) to combine them into a browser-friendly file in your distribution directory.
MDN has a tutorial which walks through setting up a basic project in Parcel.

How to imitate my library is a node module without uploading to the NPM?

If I'm developing a library which work is based a lot around of current working directory and the filesystem generally, a lot of paths resolution, and I want to see how it will behave when will be installed as a node module, I don't want to get unexpected results when I'll upload it to the npm. How do I test my library behavior pretending it's a node module? Is placing its folder in node_modules enough?
Make a local package and install it everywhere:
$ npm pack
it will generate a zipped file, so you can copy somewhere and install it.
// another project
$ npm install /path/to/pack
Resources:
npm pack,
Add local package
Absolutely you can use npm link too. link

Releasing a Javascript library for client use

I have a Javascript library that I wrote for a client. This is written in typescript using webpack and "compiles" into javascript. I want to give the client access to the distribution files but not the whole source. Ideally they can install from the command line to make installing updates easy.
The library provides some javascript functions. The client would install the script in one location on their server. They could then include the javascripts in their web surveys as they need it.
+project
+dist
-main.js
-vendor.js
-index.html
-README.md
-LICENSE.md
+src
-index.js
-index.html
...
My initial thoughts are to give them access to a private git repository that contains only the distribution files. So my project would be a git repository, only I would have access to this repo. I would then copy the contents of the dist directory to a release directory. The release directory would be another git repo I could supply to the client.
I'm not sure this is the best approach.
It was suggested that GitHub releases may be an option - but I don't use GitHub, I use GitLab and would like to continue to do so.
npm also doesn't seem like a good choice. It installs files into the node_modules directory and creates a package.json file. That's going to be confusing to my client and isn't "clean".
It sounds like a second git repository as submodule could work for you. On your side it would receive the built files, and on the clients side they could consume them.
I'd suggest making use of tags to indicate significant versions in the submodule
By using a separate repository there is no risk of leaking the original files.
Alternatively you could package the files as a zip, and upload somewhere like S3 as part of your ci process, and write a script to give the client that can automatically download the distribution files - but this seems more complex than just using a package manager like npm.

Including JS plugin files directly in Github repository?

I am relatively new to using git and GitHub, and I am working on my personal website. I am using the JS plugin Slick, a responsive carousel feature. I downloaded all of the necessary files and stored them within my local repo. The size and content of the Slick zip folder is much larger than the files for my site at the moment, so when syncing with GitHub this makes my project appear as 75% Javascript, whereas the actual website is not.
Am I doing this correctly, storing the files for my JS plugin directly within my repository folder? Or should I be using some other method to implement Slick on my site? Or is this just something I should not be worried about? Thanks
If you're just using one library, manually storing it in your Git repo is fine. You'd have to manually update the files if a new version is released, but that's not a big deal for one library. (And you might not even care about updates to this library).
However if you're using more than one library, I'd highly recommend using Node Package Manager (NPM) and a build tool like Webpack.
Here's an article that introduces these tools (plus a few others): https://medium.com/front-end-hacking/what-are-npm-yarn-babel-and-webpack-and-how-to-properly-use-them-d835a758f987
For using git, you should store your dependencies in a folder that is in your .gitignore. If you install browserify or another similar tool like webpack, you can use the npm package manager to create a dependency list file with npm init that allows for easy package installation with npm install by anyone. You can install packages slick with npm install --saveslick-carousel and use them with require() in your main js file. Then, take your js file and run browserify jsfile.js -o outputfile.js and it will package your js and your dependencies together to be used by the browser
When uploading to your git repo, add a .gitignore like this one for Node. This prevents your dependencies from being uploaded to the repo and instead when someone wants to run your project, they must run npm install to get all the dependencies.
Browserify gives an output JS file you add to your web server, the name of this file should be put in your .gitignore as well. Your code is stored in the js file you pass to browserify and other people can still access it without the output file, but they need to run the browserify command to package your code.

Is the same a package.json and a composer.json?

Hello i would like to know if a package.json is the same as a composer.json.
I need to create one file with some content, i required to put it in a package.json file but in the project there is a composer.json already. So can i work in this file or they work diffent?
Thanks
They are not the same
package.json is a npm file to keep track of npm packages.
composer.json is a composer file to keep track of php packages.
Best difference between composer.json & package.json file.
composer.json
Composer is a package manger tool for php.
composer.json manages the PHP dependencies.
For Example composer require fzaninotto/faker. This command will open and write to the composer.json file and download all the dependencies
package.json
package.json manages the Node dependencies.
All npm packages contain a file, usually in the project root, called package.json - this file holds various metadata relevant to the project. This file is used to give information to npm that allows it to identify the project as well as handle the project's dependencies.
They are different files. composer.json is for Composer, a package manager for PHP, whereas package.json is for NPM or Yarn, primarily used together with Node.js.
In addition to the information you've already been given, about package.json being a file to manage Node dependencies, there is another possibility.
Composer also uses a packages.json file (note the plural) to define a composer repository. It consists of composer.json objects together with information about where to download the files from. https://getcomposer.org/doc/04-schema.md#repositories
Your question's unclear about what you're trying to do. Whilst you tagged javascript, you don't mention it anywhere in the question itself.

Categories