I'm using dynamic package feature ("uses") to load packages dynamically in a classic toolkit app.
However, the dynamic package requires additional classes from another packages.
Building the app in production mode does not include those additional files (from second package) in the combined package file.
How can I add the required classes into the dynamic package build.
App
requires: ['packageA'],
uses: ['packageB']
PackageB
requires: ['packageA']
Currently only those classes are included (from packageA) which are requires by the App but not the once that are required in PackageB.
I think I was able to find a problem. I was using old style .sencha directory in the app which was using old build.xml file. I removed .sencha directory and updated the build.xml file from the latest ExtJS examples and it started to work correctly.
Now all dependencies from PackageA are loaded properly into app.js file.
I have an existing MVC project built with Yii2 (a PHP framework) which generates and serves HTML pages.
I'd like to write just one complex Component (with 3rd-party modules and a lot of other dependencies) only for a page (generated by Yii2); so it's important to clarify that I don't want to leave all the frontend side to ReactJS and I don't want / can't migrate to a complete frontend app managed by ReactJS.
What's the best way to integrate ReactJS (with its stuff like npm, Webpack, etc)?
Should I write the ReactJS app in a "npm environment", bundle everything and include the "build" static resources into the Yii2-generated page?
For complex scenarios it is better to use "npm stack" to build your assets and create asset bundle to only register files generated by tools like webpack or gulp. Yii tools for compiling and compressing assets works fine for simple cases, but they're very limited when you compare it to tools from npm ecosystem.
You could look how official website of Yii Framework was build: they used yarn and gulp to build frontend assets and one simple bundle to register generated files. The main difference from normal "npm fronted flow" is that they used assets-packagist to install frontend dependencies.
I have created a TypeScript module named My.Models that contains several models and I have two applications that need to use this module, neither currently use TypeScript.
The applications are a client-side Angular application and a server-side node.js application.
What is an approach that would enable me to make changes to the My.Models module, and then easily have those changes passed on to the consuming applications?
The easiest way is to publish your module to npm. This may require a couple of changes to your angular setup if you aren't already using npm modules in your angular app. We use webpack with Angular which allows you to write and require common js modules(NPM). Browserify is another option for using common js modules. If you don't want to do 100% commonjs/npm then you'd need to publish to npm for your node app and bower for your angular app.
Then you just publish a new release of your shared module after you make your changes and then you can update your Angular app and Node app.
You can use private npm modules or just publish your module to git(How to install a private NPM module without my own registry?)
I'm trying to set up a client-side app workflow with yeoman (http://yeoman.io/), and as I'm coming from Rails background, I'm used to the niceties of the asset pipeline, which is backed by Sprockets (https://github.com/sstephenson/sprockets).
I'm struggling to make all the parts play nice with each other, and already spent a few hours trying to figure it out.
The first question that comes to mind is, is there a well established (e.g. convention over configuration, like in Rails world) way of developing a client side application with yeoman? Some definitive guide (besides the basic webapp-generator guide), perhaps?
Some suggest using requirejs (which I rather not use, because while it simplifies things in development, I'll need to jump through hoops to package the app (e.g. use Almond.js or AMDclean.js, or incur the unneeded overhead of requirejs).
My setup is:
Coffeescript, Backbone + Marionette, Handlebars for templates and ZURB Foundation with SASS.
What I'd like to accomplish in the end is the following setup, while using bower for managing the 3rd party dependencies:
In development:
Have something like Rails' manifest for javascript, so I can declare the order of dependencies, which will exploded into the the index.html
For all .scss files a .css entry added to index.html
Each file watched and compiled when needed
In production (dist):
All .scss files compiled, minified and concatenated to app.css
All bower files concatenated and minified to vendor.js
All application coffeescript files compiled, minified and concatenated to app.js
All templates compiled, minified and and concatenated to templates.js
index.html modified to include only those four files.
Is there something like this setup available?
I'm also open for suggestions and/or other alternative workflows.
Yeomam won't get you as close to a Rails workflow as you might expect. My two cents is that you take a look at something like Middleman has it does what you want out of the box.
Yeoman way
Using generators
You can use Yeoman generators and try to find out the combination of generators that will better suit the stack you are looking for, from what you describe I might take a look at:
webapp
backbone
maryo
At this point most of your requirements (both development and production) would be fulfilled:
a well defined project structure
compile coffeeScript and .scss
watch and compile
generators for model, view, collection, ...
compile and minify all files for production
You can use multiple generators to customise your own stack, every time that Yeoman detects that a generator overwrites a existing file it will prompt what to do, and you should be able to manage the conflict by yourself. Some framework-generators will obviously clash (it wouldn't make sense to try to use a angular generator on top of backbone).
Fine tuning
You can use sub-generators to scaffold more specific parts of your app, see Addy Osmani video.
Building generators
If you feel limited by some of the choices that a generator might impose (e.g. you prefer browserify instead of requirejs) you might want to fork a generator and add that as an option. You can even build a generator form scratch that will build your custom stack!
Grunt and Bower way
Yeoman is build on top of this two, but you can opt out at any moment and build your own stack using this two. You can add your dependencies through bower, and your tasks using grunt. There are plenty of examples that can give you some guidance, you could start with Yeoman webapp. There are also good examples at github like juanghurtado/puppeteer.
There are 3 files that you must keep an eye:
package.json — all you node dependencies go in here
bower.json — to manage the client dependencies
Gruntfile.js — here you define the tasks
Wrapping up
Maybe I'm stating the obvious but Yeoman does some magic work and helps you managing Grunt and bower, this magic only happens when you fully understand how this 2 work. So I would recommend that first you dive into some code and fully understand how Grunt and Bower work, and then you may use Yeoman magic.
Some other tools
You asked for some suggestions, here it goes:
gulp.js An alternative to Grunt. More you dive into Grunt more you will want Gulp (IMHO).
browserify An alternative to Requiere. Read this
assemble Static site generator for Node.js, Grunt.js, and Yeoman
Roman,
Answer for your first question, here is a guide on how to use Yeoman: http://code.tutsplus.com/tutorials/building-apps-with-the-yeoman-workflow--net-33254
If you want to use coffeescript by default, just pass the --coffee param
yo webapp --coffee
handling the assets order you can handle from the index.html file.
When you want to get the app ready for production just type the
grunt build
that will unify and minify all of your assets and throw it all dist folder.
To customise what you have in the build process you would have to write your own or customise the grunt build task, so that it will do exactly what you want.
Hope i gave you some useful information :)
Not an answer to my original question, but rather a pointer for someone who'd like to implement the same workflow I was looking for. I ended up writing a custom Gruntfile, using the grunt-injector to do the "explode the assets to the index.html" part, grunt-bower-install to add bower assets and configuring the grunt-usemin, grunt-contrib-concat, grunt-contrib-cssmin and grunt-contrib-uglify accordingly.
I'm developing a DotNetNuke Module using the nonIIS method of module development. Is there any way to include a 3rd-party assembly in your module (when setting it up for deployment)?
I thought about adding it as a reference to the dotnetnuke_nonIIS website project as a whole, but that doesn't seem right considering it's a dependency of the module.
Whatever your local development environment may look like, you will most likely want to be able to deploy the module to a DNN site on its own.
To do that, you can create an installable module zip package - which consists of all of your module assets and a manifest file describing them so that DNN may process them and perform the appropriate actions (run scripts, deploy assemblies to the bin) upon installation.
Check out the DNN wiki for more information about packaging.