Best way to handle an npm packages dependencies? - javascript

I am trying to breakout a couple of Vue.js components from a primary application into an npm package stored on a repository. This package can then be imported and used across two separate sites. I am using Webpack to bundle everything but have had a few queries about the layout that should be used.
Seeing that things like Vue.js and Vuex will installed as dependencies on the main application, I know that the package will have access to these once installed on the two main applications.
My primary confusion is how do I deal with dependencies that belong to the package only, do I bundle this as part of the webpack and will running npm install on the applications automatically install the 'dependencies dependencies' if you will? Is there a general standard for these things?

The simplest thing to do is list them in your dependencies section in package.json. The package manager tool you're using (usually either npm or 'yarn`) will take responsibility for deduping the dependences, so if your parent app and your subproject both have the same dependencies, you'll only end up with one copy in the final bundle.
I would strongly suggest that you be looser on version numbers in the component projects then you are in the parent project. So in the parent maybe you say the dependency is "vue": "1.2.3" and in the component project it's "vue": "^1.1.0" or something along those lines. This way the parent can control the specific versions and your component picks up the actual version from the parent.

Related

Sharing configs in multi module javascript project

Let's say we have a project with lots of sub-packages:
👩‍🍳 project root
🍔sup package a
package.json
tsconfig.json
webpack.config.js
🍟 sub package b
package.json
tsconfig.json
webpack.config.js
This kind of structure most likely contains lots of redundancies, in both, settings and dependencies. I would like to have a way to manage these common settings and dependencies in a centralized way.
For example:
If a new sup package 🌮 is added, it would be nice, if common settings could be inherited from some kind of a centralized setting-thingy
If the version of a dependency, that is used in several sub packages, is changed, I would like to have a way to change the version at some central point, so that all sub packages "see" the new version.
I would like to change a property in all tsconfig.json's in one step, instead of editing all tsconfig.json's manually.
🤩In essence, I want to apply the DRY-principle to a project configuration.
I looked into npm workspaces, lerna, yarn, webpack, but didn't find anything that would do all of that. How could this be achieved?
🙄In Java, I would come close to this using Maven. There I could at least manage the versions of my dependencies in a central config. Isn't there something like that in the JavaScript universe?

Using helpers in a Lerna monorepo

I have a Lerna powered monorepo which contains various packages that are published to NPM. Within this have various helper functions that live on the root of the repo and are shared by a few packages.
The issue I have is that when each package is built with Babel, the transpiled code uses require to get those helpers. Obviously this doesn't work as when a package is published it needs to be completely self contained - those helpers are not there.
Is there a way to solve this? I don't want to have to duplicate helpers between packages.
When using lerna bootstrap --hoist I still have the same issue.
Well the easiest solution i see is to create an helper workspace that you do not publish when using lerna publish.
You will be able to set this "helper" workspace as a dependency of each of your workspace, therefore avoiding code duplication.

Package Angular 6 library without dependencies

I have an Angular 6 library which contains couple of modules with its routes. This library also works as a standalone application.
I have used ng-packagr to pack and publish the library. When packing all the dependencies included in package.json dependencies also gets shipped and is installed when consumed by an application.
This behaviour results in duplication of angular core libraries and app does not start.
One of ways i have handled is include all the dependencies as devDependencies in package.json, so they wont get shipped. Is there any better way to handle this without moving to dev dependencies ?
It looks like having dependencies as devDependencies is the solution for now, as having just peer dependencies works when inported as a library but it doesn't install deps when using in an application.

Why does Ember installs everything as devDependencies instead of normal dependency

Ember CLI applications have a package.json that lists everything as a dev dependency. Even stuff that is needed in the app's production version. For instance packages like ember and ember-data are installed as devdependencies.
As a reference, here's a sample of what I'm talking about: https://github.com/ember-cli/ember-new-output/blob/master/package.json#L17-L38
What's the reason for this?
In the context of application:
As #Lux mentioned in the comments, you don't need them after the build.
The output of the application is the build, that is supposed to be the final product. Further, you generally don't depend on another application. You generally depend on a package or an addon.
In the context of addons:
I think there is an opinion to display all of the addon dependencies of an application at the application's package.json file. By doing this way, you can prevent that an addon unintentially adds a js file to the build.
As a result, the ember way of managing dependencies is to leave all of your dependencies at your devDependencies and add all of the dependencies of the addon to the application's package.json with default blueprints. So the end user can tune them.

Split a javascript Javascript project in multiple package using webpack ou npm

I'm trying to build an application that have to run on Windows(PC), Android and iOS.
For this, I will use Electron (for Windows) and React Native (for mobile plateforms). Both will be built with React and Redux. This way, I will be able to implement the logic in Redux reducers and middlewares and use them in both projects.
From now, I have done a POC for the Electron app using webpack. The reducers are currently directly in the app code. I want to extract the Redux relative code in a seperate package to allow me using it in a the React Native project.
I can make an npm package for my Redux module containing the reducers and the middlwares but this way, when I will compile my application, webpack will not compile my seperate package, it will use the precompiled version.
So What I want is to be able to make a separate package but still compile it at application compile time (because it is still in developpement and the dev is very closely related to main application dev).
Do I have to do it only with npm or with webpack as well ?
I'm pretty new to the Javascript dev stack.
I think you have different ways to handle that problem.
You can use NPM package. But in code of package, you will store not only original source code, but compiled code too. I mean before publish that package, you'll need to compile it in normal ES5 code.
I think you can use submodule system provided by Git. You should have separate repository with common code of your reducers. And in each project (Electron, RN, etc.), you will have a directory with git submodule. Webpack should compile code in that directory normally without any problems.
UPD:
About submodules you can read nice article here: https://git-scm.com/book/en/v2/Git-Tools-Submodules#Starting-with-Submodules
In few words, in project it will looks like:
cd yourProjectFolder
git submodule add https://github.com/TalAter/awesome-service-workers submoduleDirectoryName
It will clone repository to your project, and create .gitmodules file. Code from submodule will not exists in current project repository. In remote repository it will contain only link to submodule, but on your machine, you will have full code and you will be able to compile it.

Categories