We have a current ReactJS project and we build a custom grid, input, error handler, etc for it.
now we start a new project and we want to share our components code between projects. we do some research and find bit platform bitsrc.io
so pleasant and good and we actually share some code between our projects with it.
the only problem is bit has a dependency checker for the import statement.
we add most of the dependency to bit lifeCycle but some of them is a config file and we want them to be different in our projects.
can anyone know the way we could ignore config import dependency to the bit?
//make bit ignore this file in dependency checking
import GeneralConfig from 'Modules/GeneralConfig/GeneralConfig'
Generally speaking, if you ignore a dependency in bit, the component will not be truly reusable. This is becasue other projects may lack a dependency for the component to function.
To ignore a missing dependency, use the --ignore-missing-dependencies for the bit tag command.
What I suggest is for you to inject the configuration to the component, rather than having the component depending on the configuration.
Related
Anyone that can point to any documentation on howto reuse code in lit-element.
The problem now is that if I declare an element, in my case a close-button and I want to reuse it by importing it into 2 or more lit-elements, there will be an error in the browser about the close-button being declared more than once.
Understandable enough, but how do I reuse a component, I could of course move the button to a separate file and add it to the document, but then there would be dependencies on that for other components to work.
Any suggestions
If close-button self-registers itself, with a call to customElements.define('close-button', ...), then you should be able to import its defining module and not have any errors due to the module caching behavior of JS.
You must have multiple customElements.define('close-button', ...) calls, so I'd make sure that 1) it's self-registering and you're not registering it again in each component that uses it, and 2) you're using standard JS modules.
After investigating a bit more, I concluded that sharing HTML templates might be the way to do it.
I'm new to webpack, and am trying to get my head around how I can switch an existing project to using it (am now using React in parts of it, so it has become necessary).
The kinds of things I am uncertain about:
As the package.json contains all my server side stuff too, will it not try to compile all this into the bundle.js?
My project contains a huge number of statically served files, and also a load of EJS generated pages. What's the best method for converting everything to webpack, I'm thinking it's going to be a bit of a headache to switch everything to 'require' statements instead of tags, but I guess it's the only way of taking full advantage of the benefits of webpack? Are there any recommended methods (or even scripts that will handles these changes for me?!).
Webpack will take care of "tree shaking" for you -- that is, it will only include the modules that your entry points explicitly use, no matter what is in your package.json file.
Looks like there is some support for EJS already in Webpack. A good conversation of it is here: https://www.npmjs.com/package/ejs-simple-loader#purpose You can then transition gradually (or not at all) as need be.
1.The backend dependencies in your package.json is unrelated to your frontend stuff. You just need to indicate the correct entry points.
FYI Entry Points
2.My suggestion is that you can find one EJS loader in GitHub to solve it.
FYI Loader
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.
I'm developing an DSL with jetbrains MPS. It's not obvious to use, but I succeeded so far with the design-part.
It's possible to right-click on a solutions node and "run" it, assuming the language is executable (extends executing.util). Plus I use a seperately developed jar as a library (used by the generator).
I build a new project to test, as simple as possible, added some extra nodes and loops in the generator, the error occures and it can't be undone.
As far as I can see, there are several possible sources of errors.
dependencies (they are tricky in MPS)
my jar
wrong cached files or so
Executing "run" causes the following error:
error: could not find or load main class MySolution.package.map_concept
Has some of you out there experience with this?
Tell me, if there are some extra information that would help.
It seems that you have added the jar file as a model to the language, which makes it invisible for the solution. Following the instructions at https://confluence.jetbrains.com/display/MPSD32/Getting+the+dependencies+right#Gettingthedependenciesright-AddingexternalJavaclassesandjarstoaprojectruntimesolutions and creating a separate library solution worked for me.
To me this looks like a problem of the generator. Have you fully rebuilt the project - right-click on the "project" node in the structure tree?
Is the root mapping template correct? If you can share your project, I can have a look.
A small tip that could have saved me some time and might also solve this problem for someone else, even if you followed the instructions in other answers.
When prompted to add your libraries to modules after including the libraries on Java tab, dismiss the window if you already included them in the first place on the Common tab. Otherwise they are listed once despite having been added twice, leading to a compilation failure.
I have a CoffeeScript project (called jAddressParser) that I am hoping to turn into reusable module. Unfortunately I am not overly familiar with how to modularize CoffeeScript for such a purpose, while maintaining sensible interoperability with an existing project.
The project in question parses address strings - no short order, to be sure. However for the purpose of the project I am working on, this strategy should work and it is possible someone else may benefit from it and perhaps others may make some useful contributions. Everybody wins!
So what I have is code laid out in a directory like this:
/
README.md
LICENSE
package.json
/src
main.js
main.coffee
canada.coffee
iso3166.js
/test
/build
In an ideal world, my workflow would be like this:
Test the above javascript from the command line. I would think Node.js is the most suitable way.
Compile the files in /src to a /build/jAddressParser.js file. I would think r.js would work well for this.
When all is ready, copy the jAddressParser.js from the /build to my web project.
Include the jAddressParser in my web project with the appropriate requirejs call (i.e. it would be AMD-ready) e.g. require(['jAddressParser'], -> ...)
Since it seems I have to include the dependencies (lodash, requirejs, require-cs, XRegExp, CoffeeScript) I expect I will do this by putting specific versions in the /lib directory or by using git submodules (though submodules seems to be a bit of overkill for such a small project).
I have never created a reusable CoffeeScript module, and I was essentially unable to find a good reference on how to perform the same for a web-module (there seem to be some decent examples for projects that are node.js-only - thought I would certainly love to see a list of more). I would be quite grateful for any thoughts or references that may shed light on the viability of the proposal above, or how you yourself might go about organizing such a project?