Q. How can the generator-jhipster leverage an internal distribution point, e.g., Nexus NPM, &tc. for jhipster blueprints?
Background
We are adopting JHipster for several major application and service initiatives building on the Java and Angular integration and tooling. We will have changes to some of the standard behaviors and will introduce an internal blueprint and a corporate theme (meeting branding standards).
What is not clear in the documentation is distribution of the blueprint and theme. Our blueprints and theme are not, naturally, suited for distribution on the JHipster marketplace.
A .blueprint folder is an option but not ideal for multiple teams and what may be many projects. npm link is not a shared configuration, requiring each team member, across multiple teams, working in different sprints cadences, &tc., to execute. I've given some consideration to git submodules, and while recently improved in Git, has dev workflow friction—and is esoteric enough—that adoption and maintenance might have to high a threshold at scale (and don't get me wrong, I loved—loved—the "vendor branch pattern" seen in SVN, coupled to SVN exports.)
Is there a hook into the generator to point to an internal distribution point?
Thanks!
I think I answered my own question reviewing other blueprints.
The JHipster Marketplace is optional and promotes blueprints for wide use. A blueprint may or may not desire this visibility.
Blueprints are NPM packages
As an NPM package, the "namespace" consists of the prefix generator-jhipster-, e.g., generator-jhipster-myblueprint and is resolved from a registry.
Given #3, if your organization has an NPM registry, e.g., Nexus, Artifactory, other, generator-jhipster --blueprint myblueprint resolves normally.
Feedback is appreciated.
Related
I'm maintaining some large NodeJS applications(micro-services, apps), which consume many(at least 100+) dependencies.
Updating those dependencies to fix a security vulnerability forces me to spend valuable development time.
Is there any way to automate package updates across repositories?
We're using GitLab for SCM.
I had thought of some options like:
Separating out core dependencies into a base level library.
Maintain a repository that specifies security-cleared dependency versions and repositories to be updated whenever the cleared list changes.
Any additional suggestions/examples?
Just to help shortlist approaches mentioned in the question:
1. Separating core dependencies into a "Core" library.
This can reduce the number of updates. But the libraries based on "Core" sill still have their own dependencies, which may be prone to vulnerabilities and the update cycle must be repeated for them manually. This approach just procrastinate the manual updates.
2. Maintain a repository that specifies security-cleared dependency versions and repositories to be updated whenever the cleared list changes.
Couple of options here:
Article on automating via pipeline scripts
GitHub: Use next-update + Hub CLI
GitLab: Use next-update + Lab CLI
Implement dependabot-core(GitHub) or dependabot-gitlab(GitLab)
Implement renovate.
How can I share components across multiple react projects without having to publish them on a public package manager like NPM?
Option 1: You can use npm and use private packages so they're not external facing. There are also artifactories and scoped packages that usually represent company-wide projects that can be public or private. See https://docs.npmjs.com/private-modules/intro and https://docs.npmjs.com/misc/scope.
Option 2: Essentially, you can develop projects with a flattened structure. You can then import various projects and/or components into other projects or folders. This is entirely dependent on your codebase and configuration. With this model though, a lot of times publishing to npm comes fairly naturally since each folder may be its own project with its own package.json.
Updated:
Option 3: Bit focuses on the composability of components from everything from the little things like a button to the actual view and app itself—each target is its own package. Overall, it's an opinionated, yet customizable framework that can enable quicker development, managed dependencies, and organized code.
Option 4: RushJS is a monorepo manager built by Microsoft that allows for flexibility of different kinds of apps and services utilizing pnpm underneath (as opposed to yarn and npm), which alleviates problems that stem from dependency issues.
Check out Bit:
Bit is an open-source cli tool for collaborating on isolated components across projects and repositories. Use Bit to distribute discrete components from a design library or a project into a standalone reusable package and utilize it across applications.
You could also upload them to a private git repo such a Github and then pull them in from there.
Ryanve has a nice example over here: https://stackoverflow.com/a/28729646/1592783
You could create a repo of shared components and then have your Node.js start script call a shell script to do a git pull from that repo and the move the shared components from that directory to your project's directory. That way, every time you call run 'npm start' you will have the latest version of the shared components loaded into your project
Anyone can publish their Node.js package to open Node Package Manager (npm) pool.
Is there any security checks for published packages so that I can be sure that a new package won't contain any harmful code?
Also it's interesting to know if there is any voting system for node packages so that I can pick out the most voted package from a bunch of similar node packages?
The Node Security Platform is a tool designed to help developers do just that! You can test your project dependencies for known vulnerabilities in a variety of ways - from the command line, integrated with your CI system, or integrated with github.
The vulnerabilities are discovered via two sources:
A team of seasoned node.js security professionals actively auditing modules on npm.
Submissions from community members, which are verified by the aforementioned team.
It's also free to use the command line tool, as well as integration with open source github repositories.
If you are using npm enterprise, nsp is also partnered with npm to provide sidebar integration. This allows you to see vulnerability information right from the npme web ui, which sounds like what you are looking for.
As far as module popularity goes, there is a website that does this to some degree at nodejsmodules.org. I use it from time to time, but beware - they've got a very expired HTTPS cert.
Disclosure: I am an employee of ^Lift Security, the company behind the Node Security Platform.
You can also use https://nodesecurity.io/ to add security checks into your GitHub pull request flow.
If you perform a search on npmjs.com before pulling a module into your system the index of all packages on npmjs.com takes into account maintenance, quality, etc."
npm search is also a good option for npm package voting.
The npms analyzer continuously analyzes the npm ecosystem, gathering as much information as possible from a variety of sources, including GitHub, David and nsp. Using the collected information, a final score for each package is calculated based on four different aspects: Quality, Maintenance, Popularity, and Personalities
How can we organize our file-system and processes if there are multiple publishers on an npm module? Do we need a common repository (ex. GIT) or is there a smart way to use npm's own publishing & updating process?
The main issue I can't get my head around is that the initial publisher of the package is not able to get the latest version from within the package itself, is he? Unless he installs it as a dependency on another package and then updates & publishes from within that dependency.
It's certainly possible to use npm in this way, although it's probably not what it's intended for. The initial publisher of the package will create the necessary structure, e.g. using npm init, then do an npm publish to make it available to your other publishers.
A couple of things to consider. First, unless you have a tightly controlled system for taking it in turns to edit, you'll almost certainly get merge conflicts, where multiple publishers make changes simultaneously. A version control system like Git can help resolve these conflicts.
Secondly, you may not want your intermediate versions to be publicly available, for many reasons - it's likely you'll want to push out some (possibly incomplete) changes for your co-publishers to build on. Or you just might not want your code to be out in the wild during development. So you may wish to consider a private repository if you do go down this route - e.g. Sinopia, or one of the hosted solutions.
Hope that helps. For info, I use a combination of mercurial (for version control) and a private npm repo (sinopia).
I've got a VS2013 solution with a mix of NodeJS (using TypeScript) and C# class library projects (they're bound together by EdgeJS). Where the NodeJS projects are concerned, one can be considered a library (for a RabbitMQ bus implementation), two are applications which are meant to be hosted as part of a fourth project with both using the bus.
So, one project (host) which will depend on three projects (bus, app1 and app2) (it starts the bus, and passes it to app1 and app2).
Of course, I could just lump all these projects together and be done with it - but that's a horrible idea.
How do I package these projects up for proper reuse and referencing (like assemblies in traditional .NET)?
Is that best done with NPM? If so, does VS provide anything in this area? If not, then what?
Note that, aside from the Bus project, I'm not looking to release these publicly - I'm not sure if that changes anything.
In general, if something can be bundled together as an independent library, then it's best to consider this a Node package and thus, refactor that logic out to it's own project. It sounds like you've already done this to some extent, separating out your bus, app1, and app2 projects. I would recommend they each have their own Git repositories if they are separate packages.
Here's some documentation to get you started with Node packages:
https://www.npmjs.org/doc/misc/npm-developers.html
The host project, if it's not something you would package but instead deploy, probably does not need to be bundled as a Node package. I would instead just consider this something that would be pulled down from Git and started on some server machine.
With all that said, your last line is important:
I'm not looking to release these publicly
GitHub does have private repositories, but as of now npmjs.org does not have private repositories. There are options to create your own private repository (Sinopia and Kappa offer different ways of accomplishing this), but if you don't want this code available for everyone do not deploy it do npmjs.org. You can still package it up in the way I've outlined it above, just not deploy it as of yet.