I have a lot of projects that depends from a core library. I would to know if exist a pattern or a strategy to update the package.json of these projects automatically and rebuild them with Jenkins, when the core library it's update.
Do you have any similar experience?
Related
The current project is an older monorepo project, which uses yarn to manage dependency packages, and many subprojects use phantom dependencies. At present, the project is gradually migrating to pnpm, but there is a problem that each subproject uses many npm packages that are not in its own package.json. However, there are dozens of such sub-projects, and manual statistics are a very heavy workload. Is there any good tool that can help me find out all the npm packages that each sub-project depends on through text analysis? In this way, I can find all missing dependencies by comparing the subproject's package.json and add them to the subproject's package.json.
There is currently no good idea to solve this problem. In the search tool, if there is no such tool, consider using python to write a new one.
We got couple of different projects that are using main dependencies like React and TypeScript packages. Each of those projects(maintained by different dev team) is using diferent version of React and TypeScript - question here:
Is there any clever way to share/inherit/force to use specific version of main dependencies across all those projects? i.e.:
Yes, this is definitely possible. Simplest way is to create an npm module with the required common dependencies in a package.json file and publish this into your repo. Then in the projects, require that published npm module as a dependency. The projects can than further require other dependencies and override any from the parent if needed.
Working on a larger typescript project we decided to move the code to a monorepo with yarn workspaces.
We use webpack to build and bundle and everything works well (especially the linking between local modules/packages).
Since yarn workspaces will store most of the node_modules in the mono repo's root folder, the IDE (IntelliJ as well as VSCode) have problems resolving the imports to any node_modules when coding inside a "inner" project (so called "package" of a monorepo).
The strange thing is that imports are not known but on the other hand most of the time you can navigate to the correct source / definition within the IDEs for the same import if you write it down manually.
We have tried to tell IntelliJ to look into another folder for node_modules, but still not satisfying.
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Did you add any special configurations to the IDE and/or package.json, tsconfig.json?
https://github.com/Izhaki/mono.ts
It uses yarn workspaces and marry well with VSCode. I hope the README is clear enough.
Basically, use two (parallel) typescript configuration trees:
Pre-build - uses aliases (for VSCode, tests, webpack, etc).
Build - uses typescript 3 project references for publishing essentially.
IDEA doesn't provide any support for Yarn workspaces; if you miss it, please follow WEB-29250 and linked tickets for updates.
You can try adding path mappings to your tsconfig.json - see https://intellij-support.jetbrains.com/hc/en-us/community/posts/207656825/comments/115000529564
Upodate as of 2018.1.1 IntelliJ now supports yarn workspaces so if you use this there should not be a problem.
https://blog.jetbrains.com/webstorm/2018/04/webstorm-2018-1-1/
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Since you are asking. I basically ran into the same issues as you did. One solution I was looking into was disable hoisting node modules as described here. Unfortunately it seems it is not yet in the stable release.
What I ended up was ditiching workspaces for now until they fix either the IDE or release the nohoist option. Instead I am using lerna for now. It is less convenient but it does not hoist so that both the build tools and the IDE are satisfied.
Oh, I am also using IntelliJ (ultimate)
I have an app that is dependent on a framework file that I wrote. They're independent xcode project and has their own Github repo. I want to create a fastlane to automatically add the framework to the app project and do a build whenever I commit to the app repo. Right now I have to manually add the framework into Embedded Binaries and Linked Frameworks and Libraries inside the app project. I can't find any actions in fastlane to update the project's framework section.
Thanks
If I understand your question correctly you are wanting to manage an API framework project which you main project uses.
Fast lane (IMHO) is about building and managing built artefacts. Managing dependencies within your project is a different thing. To that end there are two options which I am aware of:
Cocoapods - The only option for a long time. Ruby based tool. Manages dependencies by adding builds and XCConfigs to your project. Does this by re-writing your project files. Rebuilds all dependencies when you build. My opinion - I've never been a fan. I don't like that you really need to know Ruby to use it, the way it hacks into your project and enforces it's build ideas on you.
Carthage - Newer option. OS X native tool. Updates and builds dependencies only when you tell it to. Zero impact on your project, but you have to do a little work to include the framework files. Only works with frameworks. My opinion - feels more natural that Cocoapods and the best option.
I have a webapp, that I will call core, that can have plugins (not maven plugins) added to it, but it should run and build fine as a stand alone webapp. We have a plugin-lib that the core depends on and that all plugins developed to the core also depends on.
Like this:
core -> core-plugin-lib
plugins -> core-plugin-lib
My directory structure is simple:
root/
core/
pom.xml
core-plugin-lib/
pom.xml
pluginA/
pom.xml
pluginB/
pom.xml
My first problem is: can I build the core or any plugin and also build the dependent lib? I read about modules, but as you can see, the lib has 2 parents. What I would really want is to build core and also build the lib OR if I built any plugin, I would also like to build the lib independently. And mind also, that the core does not depend on any plugin.
The second problem is: how to build the core and also build the plugins, although the core does not depend on them, and the plugins should not be a module of the core. They could, it is not a requisite, but I'd rather not as I'd like to maintain as independent as possible.
As of now, when I build the plugin, it copies itself to a /plugin directory inside the core, and I have a distribution profile in the core pom to copy the existing plugins from this directory to inside the war of the webapp. So when I build the core with no profile, it does not copy its plugins, but when I run the distribution profile, yes. This works but it is tedious, as I have to build the lib, build the plugins and build core.
I would like to know if there is any pom structure that could solve the double dependency of my first problem, and if there is any way to handle the second problem and build the plugins through the core even though they are not dependent. And, if possible, if I could handle the second problem within a profile instead of a separate pom. This profile uses the maven-assembly-plugin to create a tar.gz with everything packed in it. I would also like to maintain that if possible.
I read about modules, but as you can see, the lib has 2 parents.
I think you mean that the lib has 2 projects that depend on it. A parent means something specific in Maven: A POM that is inherited by another. In this case, I think modules are what you are looking for.
As to whether you can build the lib with the core and the plugins, then yes, it's possible. Is it a good idea? I would say, no. The plugin lib defines a contract between the plugins and the core. Generally you want to know exactly which version you are depending on, and not necessarily the latest all the time. I would recommend you keep the version of the lib independent of the other projects, and build it as necessary. Then let your core and plugins depend on the version in the local (or remote) repository that you are targeting.
If you're determined to build them together, then simply define a separate, multi-module POM, perhaps next to the others, that includes both projects as modules.
Regarding the second question, you can certainly define a separate POM that builds both the core and the plugins together. Use the same multi-module technique.