We are currently planning a website which exists out of different AngularJS apps that will make use of common services. Services will be implemented in seperate files; to minimize the filesize of the apps we want to include/concatenate only those service-files that are used in the corresponding app - so we are looking for the best practise in dependency management.
is there something like requireJS in angular or what would you suggest to handle the includes?
thanks in advance .)
I suggest to use the same organization as ng-boilerplate:
https://github.com/joshdmiller/ng-boilerplate
I use an organization close to ng-boilerplat for one project and it allowed us to be modular in our dependency management.
For me, the only build/deployment system that works like a charm for most web apps that have extremely js computation is yeoman.
This quote should describe what it is/does:
Yeoman 1.0 is more than just a tool. It's a workflow; a collection of tools and best practices working in harmony to make developing for the web even better.
So basically, it is a npm that installs all the boilerplate files, dependencies and configures your whole app with the help of generators. It uses bower and gruntalso takes care of the hard part of configuring grunt that is in charge of building/deploying your app.
I highly recommend yeoman as a modern and efficient workflow.
I personally haven't looked at the ng-boilerplate as #Julio mentioned above, but you could easily manage to configure and use RequireJS with angular of you want to. I've done it and it works like a charm.
Related
We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.
TL;DR; Is it possible to implement package inheritance in Node? Or is there a recommended tool to help with this?
I am working in an enterprise environment containing 60+ (and growing) web apps. We’ve also modularized components such as header/footer/sign-in/etc. so the web apps don’t need to repeat the code, and they can just pull them in as dependencies. We also have library modules to provide things like common logging, modeling, and error handling. We also have one main library that provides a foundation for maintenance like testing, and linting.
What I am trying to do is get access to the dependencies this main library uses in upper level modules.
lib-a
|
—> lib-b
|
—> babel, chai, mocha, etc.
I would like to have lib-a “inherit” babel, chai, mocha, etc. from lib-b rather than having to specifically add the dependencies. That way all my libraries, and eventually web apps will have the same version, and I won’t have to repeat the same dependencies in every package.json. Nor will I need to go through the headache of having N number of teams update the 60-100 apps/libs/whatnot, and having to deal with them complaining about maintenance.
I do understand this goes against the core of npm, but on the level we are using this it’s becoming a maintenance headache. Going more DRY would certainly have it’s benefits at this point.
So to repeat the original question at the top - Is it possible to implement package inheritance in Node? Or are there any recommended tools to help with this?
I have seen the following tools. Has anyone ever used them? or have thoughts on them. Are there others?
https://github.com/FormidableLabs/builder
https://github.com/Cosium/dry-dry
It's a bad idea. You should assume that you don't have control over the dependencies. How else would anybody be able to make changes to the dependencies?
Suppose lib a from your example uses mocha. Since it depends on lib b which also depends on mocha, you could decide to not list mocha in lib a's package.json.
If somebody refactors lib b to not use mocha anymore, lib a will fall all a sudden. That's not good.
We work with equally many projects. We use Greenkeeper, RenovateBot, and some tools that apply changes to all our repos at once. In the long run that's probably a better strategy for you than going against Node's dependency model.
I want to write a node cli application and im wondering how i should structure the application. Im fairly new to node and im a confused with all the design patterns used when building such a application.
I want to be able to call the application from the command line, but also use it as a node module for better testing.
Currently i have one file with lots of functions that get called directly from the cli, but i feel this is rather difficult to maintain.
Is there any good writing on how to do such things? i looked at rimraf but it confused me even more. Thanks for your time
I don't know if there is a "right" way to do it but I can tell you how I have dealt with a problem similar to yours. I wanted to create a CLI and a visual studio code plugin so people would be able to use the functionality both from VSC and from the CLI (for those that don't use VSC), so the approach I took was to put all the logic in its own package and then create two other packages that included the first one, one for CLI and one VSC plugin that required the "logic" package.
In the CLI package you would only have code strictly related to command handling and then the real meat happens in the logic package. In my case the VSC plugin package had very few lines of code, just configuration and the calls to the needed functions.
Then regarding the structure of the code some recommendations:
expose only what is strictly necessary
isolate your code in different files/classes based on common functionality (and go to point 1)
test your code
lint your code
But those are common sense and language independent recommendations.
There's no one "standard" way to structure Node.js apps, however you will notice that many authors follow similar patterns. Instead of having one file containing all code, it should be split out into modules, grouped by function. Have a look at this repo on Github, it has some very good suggestions about Node.js best practice https://github.com/i0natan/nodebestpractices#1-project-structure-practices.
A couple more pointers I would add: Ensure you're logging any errors, consider using something like Winston.js for this purpose. Also have some mechanism in place to restart the service if a critical error occurs, e.g. Forever.js.
Ensure likewise you're unit testing, there are some good test frameworks, Jasmine, Mocha, Cucumber.js.
This should be a stupid question, but I can't for the life of me find any explanation of this.
In Nuget there are two packages that looks like the main-packages: AngularJS Core and Angular JS. The former have The AngularJS Team as authors, just like the rest of the other angular modules, and ~200k downloads. The later have different authors Fitzchak Yizcaki, Dov Landau not seen anywhere else, and the id of the package is not in the same format as the other packages but this has ~350k downloads.
Now, by looking at the dependencies on the other packages, we see that they refer to AngularJS.Core so we now that this is what we want. I assume.
But what is the other package, and why does is almost have twice the downloads?
It turns out that Angular JS package is the original main package, and that all these other modules including AngularJS Core are the result of an initiative to partition the angular framework.
Darn confusing start when one is about to get his hands dirty, some explanation about this in the description of the packages would be nice.
Late to the party here, but I'm sure this will benefit someone in the future:
I have been messing around with embejs and I have been using default index.html with script tags to render templates on the page, sufice to say my index.html file is littered with:
<script type="text/x-handlebars" data-template-name="aisis">
</script>
That I would like to split up. Now I have worked with ember a little bit in rails applications, but this app doesn't have a back end, doesn't use anything other then javascript and html as its a simple internal app.
My question is, how do I split this up into partials and various other templates and still keep the app nice and small, nice and simple? I have seen a bunch of ember tools out there that generate or scaffold projects for you, but I get lost and confused fast. Where as the way I have been doing it has taught me a lot, it's just my project is massive in one index file...
Ember is designed so that each route should correspond against a template. Whenever you enter a new route, a corresponding template will automatically be rendered unless you override the "renderTemplate" hook.
Try going through the "getting started" guide here: http://emberjs.com/guides/
I would recommend looking at the yeoman suite of tools: http://yeoman.io/
It includes an Ember generator that will scaffold your project, create your bower dependencies, generate a grunt file for builds, etc. Install generator-ember to get started with the scaffolding.
Just create an empty folder, and from there use yo ember to get a complete working app. Take a look at what is generated and you can get some ideas of what to incorporate in your app.
I would check out Ember App Kit. It lets you break up the templates into various files in addition to automatically importing correct modules, linting your code and providing various build options.
Ember App Kit (EAK) is a robust starter kit for developing
applications in Ember.js. EAK makes it easy to develop, build, test,
and deploy applications independent of any back-end build process.