I am looking for some tool or npm package that we can use to verify our used npm packages against certain critiera, e.g. that is was updated in the last 6 months or whether it has a certain license (e.g. MIT).
Especially the check regarding the last update date seems to be not that popular as I couldnt find anything regarding that.
In the best case, something that we can integrate with GitHub Actions so that we can automate that check.
Thanks a lot!
Greetings,
Philip
I already looked for tools / ways how we can get that data, e.g. npm show or https://packagequality.com/. However, all of them would require us to do some scripting ourselves, which I am trying to avoid.
I didnt find any tool that could be used for that, but I found a way how I can fetch the relevant data from the NPM Registry.
Requesting the following endpoint (e.g. for axios): https://registry.npmjs.org/axios/
This will return a key called time that contains the release dates of all the releases. You can then just select the latest version of it and get its date.
Consider run dependencies checker tool that npm built-in
https://www.npmjs.com/package/depcheck
It might not satisfy your needs in certain areas
So npm link is something that comes up a lot, but I haven't seen a successful implementation to date.
My wish is for the following workflow:
I have an application that uses two packages on NPM which somebody developped
I would like to contribute to this package and see if I can add functionality I like
I'm used to editing packages live, and seeing the result in my own program
The final part seems impossible with angular/typescript, are there are ways of making npm link work with types and instant results?
Because afaik symlinks do not work, the only thing that might work is doing:
* Compiling in the packages
* npm i --save PATH_TO_TARBALL
* repeat on every change to files
Which would seem tedious at best. Am i missing some grand document which shows me how to do this, or does everybody just solely use tests to make new features?
In my Liferay module, I want to use Liferay's SomeConvenientClass.
What is the recommended way to find out what module provides that class?
So that I can quickly add it to my build.gradle.
Ideally it should either:
return the module's group/name/version,
or say with certitude that this class does not exist in Liferay or is not exported.
Until now I go by trial-and-error and copy/paste from build.gradle files found in the wild, but I am looking for a more reliable method.
I have Liferay installed, and the source code of the exact same Liferay version, if that helps.
I tried mvnrepository but it does not seem to return anything, example: https://mvnrepository.com/search?q=AuditMessageProcessor
Have you tried http://search.maven.org/#advancedsearch ?
For example:
http://search.maven.org/#search|ga|1|c:"AuditMessageProcessor"
This is more an option than a real thing, but this is how I normally do:
be familiar with package naming conventions used by liferay and
inside apps: api, service, web...
be familiar with the bundle structure used by liferay, as their
use of resource folders, which are not so obvious sometimes...
With that in mind, normally on github is enough to navigate: portal->(kernel/impl/services/apps)->app service/api/web...
But this is a natural process that comes when you spend your day inside the code.
Normally, online jar locators help, but quite often I just rely on my IDE.
On my IDE I have all set-up with Spring dependency management, after I extracted the dependencies using Gogo shell with a running bundle. With Gogo you will not find classes, but modules and packs will be listed. (Gogo is probably what you are looking for btw, as it is able to list with version numbers)
Bottom line, if you need a list as a picture of a running environment, use Gogo.
With regards to the master code, just do not trust it! When it comes to modularity and bundles versioning Liferay is pretty messy (read The dependency management problem here: https://www.e-systems.tech/blog/-/blogs/liferay-digital-experience-platform-review-7-0-ga4).
For your step 7, you will need to chose an api version and code against it. The apis are more stable. You can impose a limit for compatibility on you bnd file, which will cause the system to issue warnings. On your environment, you can catch api changes earlier, let's say, you can ask gradle to use a module with an version number but any patch (using the "+" sing), when you build with a fresh cache or if you change gradle resolution strategy to download you dependencies more frequently, if the build breaks, well, you will see it.
Helpful start point: https://dev.liferay.com/pt/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell
This is how I do, it is slow and manual, so don't hesitate to suggest other methods.
Download Liferay's source code if you don't have it already.
Run find . -name SomeConvenientClass.java. If nothing is found, you can be sure the class is not part of Liferay.
In the path to the class, find the src folder level, and go just under that, so for instance if it is modules/apps/collaboration/document-library/document-library-web/src/main/java/com/liferay/document/library/web/portlet/action/DLViewMVCRenderCommand.java then go to modules/apps/collaboration/document-library/document-library-web/.
Hopefully there is a bnd.bnd file there, open it.
If the package of the class is not in the Export-Package section, then either give up (duplicate Liferay's code into your module), or use some dark tricks. If you believe the class should be exported, you can explain your case at https://issues.liferay.com/browse/LPS-70480 for future generations to enjoy.
Module name is the value of Bundle-SymbolicName.
Version is the value of Bundle-Version.
Group is probably com.liferay, although sometimes it is com.liferay.portal, not sure how to tell.
Build. Sometimes it fails because Maven repositories are missing a version, for instance com.liferay.document.library.web 1.0.11 is not available despite being used by DXP fix pack 30. Not sure what to do in such cases except choosing a "similar" version and hoping for the best.
We have found ourselves in a situation where solutions have been imported with a different publisher to normal. So now when we have done updates to any components that are also included in that solution in a solution with our own publisher the import fails.
Is there any way that we can get the newer customisations to go over the ones from the previous solution, preferably without removing the previous solution?
Thanks
When I add AFDownloadRequestOperation I get several errors that result in the inability for me to successfully build my project...
These errors all seem to be of a redeclaration nature. My first mind is to go into the files that display the error and individually delete the other declarations.
But I figured that it may cause more errors and/or not be the best method to resolve my issue. Is anyone familiar with this issue?
I have attached a screenshot of what I see.
My best guess is that Xcode is complaining about there being multiple files in the project that declare the #interface for AFDownloadRequestOperation. Note that AFDownloadRequestOperation has never been a part of the standard AFNetworking library, so I would suggest that you make sure that you are using the most up-to-date version of the canonical source available.
You may find CocoaPods to be helpful for managing your dependencies, as an alternative to manually adding source files to your project.