The company I work for develops and maintains multiple web-based products. We have been pushing the teams to standardize and reuse 3rd party libraries of all kinds across prod. dev. We use Ivy to manage jar file dependencies for Java. We use Python eggs in combination with custom build RPMs to manage Python dependencies.
I was wondering if there is a similar way to manage Javascript dependencies (e.g. jquery, raphaeljs, etc.).
Perhaps you would like to check RequireJS or Ender.
[Update]
As of today, 31 March 2017, there are a lot of different package managers and/or tools you could use to manage front-end libraries (npm, bower, rollup, etc.), but I currently found Yarn and Webpack 2 most interesting.
Related
We have been working on our projects all tied to a single lerna repository, as:
lerna
|----- app1 - application 1
|----- app2 - application 2
|----- appN - application N
|----- commondb (common database libraries for app1, app2 to appN)
|----- commonux (common ux libraries for app1, app2 to appN)
|----- commonauth (common authentication libraries for app1, app2 to appN)
As the code grew a lot, lerna is really full of packages (40+ packages) and too much code.
We're now trying to split lerna into smaller pieces and we're looking for alternatives. Doing that, applications would need a way to import common libraries as we do today.
Certainly NPM seens to be a solution (making each common package independent and publishing it on NPM), but we want to keep our code in our environment without third party services or clouds (we have our own git server instance).
What are the current options to manage javascript libraries that we can make use of? What would be the recommended one in such a scenario?
Your decision can be greatly affected by answering the following - do you want your apps to be running the same version of the shared libraries? Or do want autonomy within the libraries, and to be able to publish and manage different versions of the libraries, where it is the responsibility on the consumer app to manage which version of the library it is using?
If it is the former, my suggestion would be to stick with a Mono-repo approach, maybe consider something like NX, where it has some nice tooling for only linting, testing, building and deploying only the affected modules, whilst sharing a common single package.json and therefore common libraries shared across multiple apps and libs
Otherwise you are looking at potentially managing multiple repos, multiple versions of each library, multiple pipelines, multiple workspace configs.
You could simply use pnpm workspaces: protocol which allows you to create a monorepo structure but without even requiring you to publish when used this way: "foo": "workspace:*". So if you wish to use this approach, then you could have a monorepo structure and just keep local packages, it will use the local code without downloading anything. I used this concept in a Vue pnpm Workspace demo. With this approach you could stay with local packages and/or go with Lerna to publish if you also want to (I prefer Lerna-Lite which is what I use) since they now both support pnpm/yarn workspace: protocol. This approach is flexible and allows you to switch to publishing (to npm or a private registry) at any point in the time in the future if you wish to, in other words there's no major code refactoring to add Lerna after the fact when using a pnpm workspace structure.
I'am trying to achieve a plugin system for my typescript SPA, but I'am not sure how to approach this in terms of code bundling/splitting.
Current setup
The frontend and backend is implemented with Typescript / ESM.
Frontend:
Vuejs 3
Vitejs/Rollup
Pinia
Backend/API:
NestJs with Express/RestAPI
The app currently consist of 3 npm packages:
Server: NestJs Server Application
Web: Vuejs Frontend / UI Components
Common: Shared models and interfaces and utilities between frontend and backend
Requirements
I want to enable third parties to implement additional modules for this platform installable e.g. via NPM or ideally by just copying the module into a modules directory or some kind of marketplace in the future.
A third party module should be able to import and use classes from the core frontend/backend and common packages similar to the core modules itself. For example, a third party module should be able to access services/models/ui-components and stores of a core calendar module.
Ideally this should work without the need to rebuild the whole frontend/backend. I'am coming from languages like Java and PHP in which you have namespaces, packages and classloaders. I'am not sure how to bundle something like this in a javascript
application especially for the frontend.
So my questions are:
How to bundle/split the core packages
How to import core packages within third party modules
How to build, bundle/split the third party packages
I assume I have to somehow add those core dependencies as externals within the third party module and provide the core bundles as UMD or ESM.
Would be great if someone could point me in the right direction and can provide me with some hints, resources, best practices or even existing/similar solutions.
hello i'm in new in monorepos world and i'm now searching about different monorepos tools
and i found two intersting tools Nx(nrwl) and lerna but i didn't understand the real differnce between these two tools so any help and thanks
2022 Update
As pointed out by my great fellow at the comment section, Lerna is now being held by the Nx team.
The best solution nowadays is to use more native approaches for publishing (as NPM/YARN workspaces) or go straight to Nx.
Good references:
Lerna is dead — Long Live Lerna
Integrating Nx and Lerna
2021 Answer (slightly outdated but still valid)
Although both are great tools to work with mono repo, they're quite different in their purpose.
Differences
Lerna is focused on linking multiple packages from the same project and managing npm publishing, and that's about it.
Nx is more focused on managing development workflow for multiple packages. It means it can scaffold packages, and for every package, you can define configurations on how to run and build them, in a similar manner to Webpack.
Nx can also work to spawn multiple processes at once. For example: run frontend and backend at the same time, without the need to open two different terminals. Similar to docker-compose.
Where they thrive
Lerna fits better for open source projects with multiple packages (because you can easily publish your packages).
Nx fits better for handling complex workflows with multiple packages.
How to choose
If you don't intend to publish your packages, Nx might be a better fit.
If you do intend to publish then, but you don't have a complex workflow, Lerna is definitely the way to go.
If you want both (publish and complex workflow), neither one seems great, but you should probably choose Nx, and manage the publishing manually. Or, maybe, use Lerna and configure the workflow manually with Webpack.
Someone can wonder if you could choose both, but I don't think they can work well together. At the time I'm writing this, Nx doesn't seem to care about being compatible with Lerna, and it Nx still lacks support for easy publishing.
An important disclaimer about terminology
I used the name "package" here because "package" is what you can publish on the internet (for example, as npm is a node package manager).
Lerna uses the name "project" as the wrapper folder of all your packages. Usually, a git repository is a "Lerna project" with several "Lerna packages".
Nx uses the name "project" to designate what Lerna calls "packages", and uses the name "workspace" to designate what Lerna calls "project" (i.e., the wrapper folder which holds all the projects).
There are two package managers for client-side Javascript, but how do they compare? Could someone explain which one excels at what?
Jam
Bower
As others mentioned in comments already there are a few alternatives in this space beyond just Jam and Bower.
Component
Ender
Volo
Both aim to provide a way to package up your assets and manage the dependencies between them for the client. Both Bower and Jam appear to have made their debut in 2012 -- Sept and May respectively.
Both are available through node/npm and if all you want to do is resolve dependencies between public libraries like backbone, underscore, jquery, etc. for your application then either solution will work and allow you some basic options to control version, where to put it in your project, and checking for updates.
As for what's different -- Bower is a bit lower level than Jam which makes it more usable to a wider audience. You can create bower components for more than just JavaScript libraries. Jam focuses more solely on AMD style JavaScript libraries. With Jam, you can specify your dependencies in the package.json file you would use with npm components already whereas Bower has chosen component.json by convention. The limitation with Bower is that it only fetches your dependencies, you still need a build system if you want to use Require.js or other solutions which Jam has chosen so you get for free. Bower is getting support from Twitter and a few other projects (Ender, Yeoman).
Apologies if this is incorrect, but one additional limitation of Jam is that it does not allow you to create your own components for distribution in a private repository. This is something Bower allows you to configure as an endpoint in .bowerrc but I have as yet found a way to do that in Jam. Perhaps I haven't searched well enough but it appears there is at least one fork for private-jam.
A few other good reads:
http://yeoman.io/packagemanager.html
http://dailyjs.com/2013/01/28/components/
Using the following breakdown of some of the popular package managers you can decide what you want to use in you development. It compares factos as
whether the manager uses package.json or other form of descriptor
what features does it support (scaffolding, compilation, having central registry)
speed
form of packages support (js only, js and css, js html and css)
module types supported
and of course some notes based on personal point of view
https://github.com/wilmoore/frontend-packagers
Do you know a package manager for web assets?
I'd like something that can download libraries such as jQuery so I can plug them into my asset pipeline. The js.* python packages for fanstatic are close, but they pick a single "latest" version of the library, which can lag a few releases behind.
Google's js cdn has the metadata for a few of them, but is mostly designed to be downloaded by the browser directly.
I've found these package managers for in-browser javascript:
CPM (CommonJS package manager), focused on Dojo packages, with an archive at http://packages.dojofoundation.org/ (about 60 packages). CPM augments the CommonJS format with a mappings field to describe how modules from dependent packages can be require()d
Caolan's Jam, whose archive is at http://jamjs.org/packages/. Here is the Jam packaging guide.
Ender piggybacks on npm for package management, and provides a client that looks like AMD (I'm not sure about AMD compatibility, which according to a bug report is left up to each package). Here are the Ender packaging docs. Here are packages with the ender keyword. Ender doesn't focus on packaging existing libraries, though its Jeesh starter pack is a modular, mostly-compatible replacement for jQuery.
Most of these can publish in the AMD format for browser loaders, and can be loaded by RequireJS. They also tend to use the CommonJS package format (also used by npm) for their package.json metadata.
I also found XStatic, which seems to be a less-active version of fanstatic, and like fanstatic wraps the libraries in Python packages. It has the same limitation (versions tend to lag), but writing a wrapper package seems simple enough that I can bake my own updates.
BPM and fanstatic are aware of non-js assets and can merge or minify CSS.
Bower, the package manager, from Twitter.
Bower is a package manager for the web. Bower lets you easily install
assets such as images, CSS and JavaScript, and manages dependencies
for you.
Bower does package management and package management only.
Bower requires Node and npm (and possibly git for some bower packages). It is also included in Yeoman, a set of tools to help developers build modern web apps.
If you are on Visual Studio 2010, NuGet is best
http://nuget.org/
The author of RequireJS has also created a package / dependency manager called Volo:
Create browser-based, front-end projects from project templates, and
add dependencies by fetching them from GitHub. Once your project is
set up, automate common tasks.
volo is dependency manager and project creation tool that favors
GitHub for the package repository.
At its heart, volo is a generic command runner -- you can create new
commands for volo, and you can use commands others have created.
Just use npm. It has tons of browser modules in it already, and is way larger than the other options:
http://www.modulecounts.com/