We have a modular monolith application, each module being an extjs app. Modules share alot of features / functionality, therefore the most of code is sitting in a common extjs package that gets imported into each module, the module themselves are relatively thin. We also provide an accessibility build, ie., everything is built at least twice (once with normal theme, once with high contrast), but for some apps more (some logic is managed through extjs macros to exclude / include different regions at build time).
The end result is agonizing build time. ~10 apps, each built at least twice, each build lasting just under 2 minutes. It's all because each app is built from scratch. Is there a straightforward means to build it together? So that instead of rebuilding extjs code / common package code / themes 10 times, it would be just built once and reused in build process of all apps?
This looks very relevant "saving and restoring sets" . But it seems to be some lower level feature, which would as far as I understand it come useful if we were reimplementing build process from scratch and tossing out app.json. Is there a clear way how to incorporate it into existing higher level features like sencha app build?
You could go ahead and build the packages (if any) separated from the application, then drop the packages in the owning directories of the build. However, Sencha CMD and the way the class system and resolving the dependencies works makes it really hard to untangle the build process, so it's hard to give a general advice here.
You might want to look into the package loader of Ext JS and the "uses" configuration option for the app.json.
Related
I started to interest in monorepo approach and Nx.js in particularly. Almost all articles talks that monorepo solve the problem of incompatibility of library versions and I don't quite understand the how. There I have few questions:
If i understood right, the idea of monorepo (in terms of shared code) that all shared code always the same version and all changes are happen in one atomic commit (as advertisement of monorepo states). So lets imagine monorepo with 100 of projects and all of them are depend on libA in the same repo. If I change smth in libA than I have to check changes in all dependent project. Moreover, I have to wait all codeowners to review my changes. So what is pros?
Lets imagine I have monorepo with following projects: appA, libC, libD and there are some third party library, let's call it third-party-lib. appA depends on libC and libD. At some time appA need third-party-lib-v3, BUT libC depends on third-party-lib-v1. https://monorepo.tools/#code-generation states that: "One version of everything
No need to worry about incompatibilities because of projects depending on conflicting versions of third party libraries.". But it is not. In world of Javascript it results in 2 different versions of third-party-lib in different node_modules. Angain what is pros?
I could be very naive in my questions because I never encountered problems with libraries, also I just started learning monorepo topic so I would be glad if someone help me to deal with it.
Having worked with shared code in a non-monorepo environment, I can say that managing internal packages without a monorepo like NX requires discipline and can be more time consuming.
In your example of 100 projects using 1 library, all 100 projects should be tested and deployed with the new version of the code. The difference is when.
In separate repos, you would publish the new version of your package, with all the code reviews and unit testing that go along with it. Next you would update the package version in all your 100 apps, probably one by one. You would test them, get code reviews, and then deploy them.
Now, what if you found an issue with your new changes in one of the apps? Would you roll back to the previous version? If it was in the app then you could fix it in that one app, but if it was in the library, would you roll back the version number in all your apps? What if another change was needed in your library?
You could find yourself in a situation where your apps are using different versions of your library, and you can't push out new versions because you can't get some of your apps working with the previous version. Multiply that across many shared libraries and you have an administrative nightmare.
In a mono-repo, the pain is the same, but it requires less administrative work. With NX, you know what apps your change is affecting and can test all those apps before you deploy your changes, and deploy them all at once. You don't block other changes going into your library because the changes aren't committed until they are tested everywhere they are used.
It is the same with third party libraries. When you update the version of a library, you test it in all applications that use it before your change is committed. If it doesn't work in one application, you have a choice.
Fix the issue preventing that application from working OR
Don't update the package to the new version
It means that you don't have applications that are 'left behind' and are forced to keep everything up to date. It does mean that sometimes updates can take so much time that they are difficult to prioritise, but that is the same for multi-repo development.
Finally, I would to add that when starting to work with NX you may find yourself creating large, frequently changing libraries that are used by all apps, or perhaps putting large amounts of code in the apps themselves. This leads to pain where changes frequently result in deployments of the whole monorepo. I have found that it is better to create app specific folders that contain libraries that are only used by that app, and only create shared libraries when it makes business sense to do so. Examples are:
Services that call APIs and return business domain objects that should not really be changed (changes to these APIs and responses generally result in a V2 of the API and a new NX library could be created to serve that V2 API, leaving the V1 unchanged).
Core, stable atomic UI libraries for each component (again, try not to change the component itself, but create a V2 if it needs to change)
More information on this can be found here NX applications and libraries
Struggling with collision of technical terms (most especially the term "plugin" which has about seven different meanings within the react development stack).
Short question:
Is there a way to pre-compile static webpack modules that can be installed separately from a main static react web application, while still sharing modules contained in the main web application? (The question as best I can formulate it using my relatively naïve react developer skills). I'd like the ability to plug in web user interface components supplied by 3rd party developers after the fact. i.e. installable runtime React UI components, not requiring react compilation at install time.
Details:
I have a static React web app that allows remote control of audio plugins (specifically LV2 audio plugins). It's a single-page static react app (that communicates via we sockets with the running application), hosted by a static C++ web server. Realtime and IOT agility requirements make a python hosted dynamic web server an runtime compilation an unattractive prospect (https://github.com/rerdavies/pipedal)
What I want to do is allow extension of the web UI using separate bundles provided by 3rd-party LV2 plugins. The ideal solution would be to allow static webpack bundles pre-compiled by the lv2 plaigns and placed in /usr/lib/lv2/<pluginname.lvw>/resource directories to be consumed by the web app at runtime. I'm using a custom C++ web server, so redirecting URLs into the /usr/lib/lv2/xx/resource directories is straightforward.
The main app would be distributed one apt package. Lv2 plugins would be compiled (potentially by 3rd party developers) against an "sdk package" provided by the main app build, after the main app was built, and then distributed in separate packages. Ideally, I'd like to pre-compile the ui code for the plugins to static webpack modules before their installers are built.
I more-or-less understand how I would do this if I were using raw CLI tools and configuration files (tsc, webpack, babel). But I can't help thinking I would be reinventing a wheel. (And I do have concerns that I'm going to incur serious version-dependency problems).
I would like to code-share the base modules (react, #mui controls, and a limited set of app-supplied components and interfaces).
I see the path through the various tools to make this happen, using my own custom build script, I think. I can get the typescript compiler to do code-splitting; I can probably figure out how to get the babel transpiler to do the right thing. And I think I understand how to write webpack configuration files that will process do sharing of modules from the main app. And a likely path to build and distribute an npm package to do the setup and build of LV2 plugin projects. And how to write supporting CMake build rules for building and installing such packages. &c. But I'm concerned that I'm going to go down a large rabbit hole trying to reinvent something that surely must exist already. And I can imagine seven thousand ways for this to go horribly wrong. :-P
So far, I have implemented the TypeScript compiler portion of the build procedure. And writing various bits to dynamicall intercept and service resource requests in the web server is trivial. But it has become painfully obvious that I also need to do babel and webpack build steps as well.
I haven't yet looked at the react-scripts package contents to see if I can steal code to build what I want there. Perhaps that's a viable path.
Is there a way to do this with off-the-shelf npm packages and off-the-shelf npm build procedures? I can find all kinds of bits to get me part way; but the integration of all the bits is rather daunting. Should I just do the deed, and start writing my own custom build scripts to make this happen?
What I am looking for is a master package/Sdk that defines my features, now I have various build version of this Sdk with customized features, now whenever I add a new feature to the master, it automatically reflects in the other build versions, I might have a lot of versions of it in the near future so the idea of keeping different repos/branches then merging them, later on, can turn into a nightmare( I do this right now).
I have thought of creating a configuration based system but as the sdk grows maintaining those configuration files will be a bigger challange than merging projects.
Android does something like this, example
I have my MainActivity( the top level file)
and I have a build version which has its own customized MainActivity
now When I update my top-level file, I see those changes in my build file too.
Note: All features added will not raise merge conflicts(As long as I am not updating old features). Any suggestion, StackOverflow reading recommendation will help.
I'm trying to decide if I should use Angular CLI for a new project. My primary reason for doing so would be to avoid the hassles of setting up a new project right now and instead focus on learning the new Angular and building the application.
I'm coming from Angular 1.x so the hassles for me stem from learning all the new tooling in addition to the new Angular. Most of the docs reference systemjs but webpack seems like the direction the community is moving in so I would like to go that route.
I would prefer to learn and become comfortable with the Angular toolchain (including webpack) but I'd like to push that off a little if possible. I generally don't prefer "black boxes" like the CLI.
I would like to start by using the CLI and then break away at a point in the future when I have time to invest in learning more about webpack, etc. My question is: What limitations does the CLI put on me, can I easily break away from it in the future, and generally what else should I consider before using it as a quick way to get started?
I started working with Angular 2 while it was in Alpha, long before Angular-cli was available. During this early stage I struggled with the build environment - I was using systemjs and a whole pile of self-built spaghetti code of gulp tasks to handle transpiling, minifying, bundling etc. For every hour I spent writing angular code, however, it seemed I was spending two hours on the build environment. Did I learn alot? Sure. Was it a good use of my time? Not very.
The angular-cli changed all of that. It was built by the Angular team to accomplish all of the development and build tasks that an angular developer needs. It is always improving and when there have been problems they have been address quickly. I now can create an ng2 project in a few minutes with "ng new projectname --style=scss." I can run immediately in development mode with "ng serve." Changes automatically get compiled. I can build for production with "ng build -prod -aot" and have my entire ng2 project ready for production in minutes with Ahead of Time (aot) pre-compilation and tree-shaking.
So my advise to anyone would be this. If you want to quickly get into the serious work of building ng2 apps, and not waste your time re-creating the build and production environments yourself, then use angular-cli.
If you have time to burn and want to learn more about what's underneath the hood with angular2, then have a go at it yourself; you will certainly gain a better understanding of things; but you'll just end up using angular-cli anyway.
I am going to argue against using the CLI.
I have been using Angular 2 from the early days before RC. Indeed there was a lot of confusion back then, having to deal with all these packaging solutions (require.js, system.js, webpack). I got to admit that it was not a pleasant time back then, and it drained a lot of time.
BUT
Nowadays, I have a strong skill set in setting up builds and deployments. I have experimented with lots of possible ways to configure it and to achieve greatness. Recently we had to develop a plugins architecture for our webapp at the office. Guess what, knowing webpack has saved my skin big time. I was able to find an initial solution which was not that great. Eventually, after polishing it and taking advantage of webpack, we have created a really nice solution, with minimal code, without interfering in either webpack or angular architecture.
There is no chance that I would have been able to do this without all the pain of having to deal with webpack constantly. I hear very often misconceptions from my peers about how webpack and angular works. I do my best to explain stuff, but nothing beats doing it yourself. I'm sorry to say, but hiding behind the CLI will do you no good. A senior developer that I can trust to create new architecture must have solid webpack, angular and typescript know-how.
If you do not understand these tools properly you will be relegated to the menial tasks of applying existing patterns never to be trusted to go out there in the wild jungle and creat the new architecture for others to follow. You need to be able to think for yourself and to take your own decisions.
Conclusion
See whether or not the CLI is the tool for your current task and choose accordingly. Don't just blindly follow the first advice you see. If you are in charge of a project and you have to call the shots, knowing webpack is a must.
I am in same situation as you, but after doing a lot of research on the subject, I have come to the conclution, that it is perfectly fine to use the CLI to build Angular 2 projects.
The CLI is supported by the Angular team and in constant development with a big community - even turorials and the NG2-Book use the CLI as the configuration.
The CLI use Webpack integrated and exposes the configuration through the CLI json, but I read that soon it is possible to use command 'ng eject' to eject the webpack config file itself (if needed).
I believe the future (even now), that it's normal to use the CLI with integrated webpack, instead of using Webpack as a seperate bundler.
I'm new to qooxdoo. I'd like to use it for an embedded web interface for an application I'm developing right now.
To keep building my application as easy as possible I'd like to stay away from using the python build scripts after every change if possible. Because the website will only be used once in a while by a single user load times etc. are also not a big concern for me.
I've read about the "build-all" target but could not find a detailed description on how to activate it with the current release. Can someone explain how I can get a complete desktop build of qooxdoo?
You don't have to run generate.py every time you change the code, only every time you reference a new class. During development it's usually relatively infrequent that you have to re-run the generator, compared to how often you will do the edit/save/alt-tab/refresh/test cycle.
But you can do what you're asking during development by using the "source-all" target, eg:
./generate.py source-all
When loading an app from a file:// url this is fine because file:// URLs are very fast, but you can optimise this manually by modifying your config.json to incorporate specific sets of classes.
To do this, in your application's config.json, add (or edit) a job called "source" and add:
"jobs": {
"source": {
"include": [ "qx.ui.*" ]
}
This will cause all of the qx.ui.* classes to be included into the ./generate.py source build of your application; obviously you can fine tune this further.
When it comes to deploying your application, use ./generate.py build because this will produce a minimised, optimised version (with debug code removed etc) which uses only those classes that are required.
If you are still looking for a build version of Qooxdoo, here is my qxSimple project. It includes some examples.
http://adeliz.github.io/qxsimple/
You can also generate your own build version following these steps :
Dowload the latest qooxdoo release
Go in the framework folder
Edit the config.json file
uncomment the //build-all line
run generate.py build-all