I am developing an application with a few modules. Each module is individually deploy-able on the server. I am using Angular for my UI.
Because I have 4 modules, I obviously have 4 different Angular projects, setup & files.
Though there are certain differences like routing, controllers, views, the external frameworks, libraries used can be very similar and I do not want to replicate all of them.
Hence I wish to have a common project/folder/directory and use these in different modules. this way I can avoid redundancy (if it can be called that). Can someone please help me understand if my thought process is correct? If so how can I achieve this?
Use a third party package manager like npm or bower. You can then add the libraries during build time with browserify or custom gulp/grunt code.
You can then bundle all you libraries into a single file and include it in you application.
Related
I am building a monorepo for a suite of React apps, and common library code. One of the packages would be a component library.
packages
app1
app2
common-ui
alert
button
I'm pretty new to the whole React/node ecosystem.
I've looked at a lot of actual UI library examples - react-bootstrap, material-design-components-react, etc.
It seems I would want to have each component in the common-ui lib to be distributed as single files, so that they can be cherry-picked when imported into a consuming app.
react-bootsrap does this by using babel to build the "lib". They build into a browser distributable, a commonjs lib, and an ES lib.
material-design-components-react does this by having their component lib itself by a lerna monorepo, with each component having its own package.json, and I believe they use webpack to build each component individually.
So my first question is,
Is a structure like material-design-components-react in my common-ui folder - kind of a monorepo within a monorepo possible?
Or would I have to restructure:
packages
app1
app2
alert
button
My second question is,
Which design is recommended by the community for a component library within a major monorepo? This must be a common structure developers have to solve when they have many client apps with common libraries. A package per common-ui component seems like a lot of overhead, but of course they have scripts to help out.
Is a structure like material-design-components-react in my common-ui
folder - kind of a monorepo within a monorepo possible?
Yes it's possible. But keep in mind, you and those libraries have very different requirements. You can think of your monorepo as small projects developed in same company., which are depending on similar 3rd party libraries and they follow same linting, testing etc.
Which design is recommended by the community for a component library
within a major monorepo? This must be a common structure developers
have to solve when they have many client apps with common libraries. A
package per common-ui component seems like a lot of overhead, but of
course they have scripts to help out.
First structure with 3 packages is most common way to start your repository/project.
In your case, I wouldn't recommend to divide your ux-library into single files. Your apps will likely use most of your ux-library and probably you won't have as much components as material or bootstrap has. Moreover, if you'd ever reach that point in your library, you can separate them later. For reference you can also check how lodash is publishing each of their functions. It's not different than your case (assuming you won't publish any fonts/images etc.).
As the title suggests, I'd like to have a common TypeScript code, mainly for server communication, that is somehow referenced by 2 Angular projects.
I'm thinking of making a common TypeScript project that is packaged and then consumed by the two, but I don't know how to do that (or if it's the best solution).
Any suggestions ?
mainly for server communication, that is somehow referenced by 2 Angular projects.
Best that you publish it as a seperate npm module. You can use use projects seemlessly from other typescript projects https://basarat.gitbooks.io/typescript/content/docs/node/nodejs.html
I'm developing several AngularJS applications and I'm looking for best practices how I can share code, especially directives, between these projects. The biggest problem I'm facing is the following:
Most of my directives contain at least one js file and a html template. The js file often contains a reference to the template. When I include the same js file from two different projects, what's the best way to handle the different paths?
There may be better ways to handle this situation I can't even think of. So, I would like to know if someone has experiences with this situation and how this is handled. Thanks!
I find it helpful to use compiled HTML templates using a build tool like https://www.npmjs.com/package/grunt-angular-templates . There are plenty of Gulp/Grunt alternatives if that one doesn't suite your needs.
Then you will need to keep your templates in namespaced directories so that your consumer applications don't collide.
Then you when you just need to consume a single compiled JS file. The templates are compiled into it. If you need to override the templates in your applicatons, just use the template namespace convention to provide the overrides.
Maybe you can write your code in nodejs style (with CommonJS), locate your files in different folders and such, and then use browserify to combine your js code into one piece. HTML templates can be also easily transpilled into js files using angular template cache and some tool like this one for gulp or maybe some similiar for grunt.
I'm currently building an angular app with browserify ends up everything is in a bundle js file including angular.js itself and other vendor libs. I am wondering is it a common practice for using browserify or I'm doing something wrong here?
Wouldn't say you're doing anything wrong; its a matter of preference.
I would personally create 2 separate bundles, application and libs, just because I prefer to have that separation in my build.
With separation, upgrading/swapping libs won't require a re-bundle of application logic, and updates to the app won't require a re-bundle of libs. Based on how your build is structured this could increase speed & efficiency, especially if you have watches in place.
As we're making our initial move into DNN and setting up projects, I need clarification on the Web Application Project model for creating DNN modules.
Should/can all modules live inside one web application project? Or, should each module be its own WAP?
What would best practices dictate for the project structure in the solution containing DNN modules?
You can do it either way. I've heard people do it both ways.
Do your modules depend on each other at all? If so, you might want to keep them all in the same project so if one gets built, they all do.
If not, I like to keep each module in a separate project just from a separation standpoint. Each module/project will be smaller and easier to manage. Just build the project and it will give you the install file.
It's just a personal preference. I know a lot of people create one solution, then keep a separate project for each module.