I'm wondering if it is possible to split up bundles using the angular cli based on a component. For instance, I would like to have multiple components in this app that could or could not exist on the same page, but reference them through separate bundles. Some kind of set up like this would be desired:
/test-app
.angular-cli.json
package.json
tslint.json
src
app
email-list
*.ts
*.html
email-compose
*.ts
*.html
links-links
*.ts
*.html
After the project is built, I would like to be able to have the following bundles:
poylfills.bundle.js
vendor.bundle.js
email.bundle.js
links.bundle.js
Is this possible?
They've prepared support for multiple apps/entry-points (which is equivalent to what you're asking) in the angular-cli.json, but they havn't gotten around to implement it yet. Here's a link to the issues page
In addition, they've announced that they don't intent to expose the webpack configuration of angular-cli, so you wont be able to use your own custom webpack config to do the separate bundling.
So for now, I guess the conclusion is, that it may not be possible (or worth the effort) to make Angular-cli create multiple separate bundles. So you'll probably have to either wait, or skip using the cli, and do the bundling "manually" (create your own bundling process using grunt, gulp, webpack or similar).
Related
i created a create-react-app and want to use filetypes like webp or mp3.
When i run my application on localhost via npm run start everything works fine, but after my deployment on my server (which uses npm run build and delivers the build folder) it doesn't load filetypes like mp3 or webp anymore. Why is this happening? i think its any simple configuration in react or anything like that, but i cant solve this problem by my own. Thanks for your help.
The issue may be with typescript (if that is what you're using). Typescript will convert .ts and .tsx files to .js, but not move most other files over to build. If they are in a separate assets directory, you have to ensure that gets deployed too. If this is the issue, you have a few choices.
You can manually move the files over to build as a 'post' deploy step (using say, a shell script).
You can use a bundler like webpack to help you maintain the references to those other assets and bundle them correctly.
I finally found the problem that caused this behaviour. Amazon AWS Amplify creates a rewrite rule for single page applications (SPA). You can find this setting under Rewrites and redirects in your Amplify application settings. There you will find a rewrite rule with following source address:
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>
...change it to...
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json|mp3)$)([^.]+$)/>
... for example, to allow mp3 files. This is also important to allow webp-Images or woff2-Fonts.
I am attempting to publish a small library of react UI components. These components have dependencies: Matarial UI, React Rotuer, etc;
When I build my code I get a warning about exceeding the recommended bundle size. I am at 451Kib. When I analyze my bundle I notice that 96.1% of it is dependencies that have been added to the bundle from node_modules.
Since I am only going to be publishing a handfull of components that are also going to be imported with webpack, is there a way to exclude the dependencies from my bundle and have them packaged in the bundle of any app that uses my components?
I think I need to use code-splitting, or lazy-loading, or something, but I am not sure of the proper way to get started.
Pieces of Advice I can give you:
Use webpack-node-externals to exclude node_modules from bundle. If your code depends on packages that won't be included in the user app - use whitelist to bundle them as well.
Also mark Matarial UI, React Rotuer (and probably react) as peerDependecies in package.json.
I understand that in react you cannot import files outside src folder.
But what is the reason for it exactly and can I disable it?
In my project react web app is only part of the whole thing, and different parts share some files (configs, build output), so folder structure looks like this
ProjectRoot/
config
build-output/
Part1/
Part2/
WebApp/
src/
...
Sure, you can copy files or create symlinks, but that's duplication and inconvenient.
This is a restriction of Create React App only.
This tool exists to get new users up and running with the react framework as fast as possible by abstracting away the tooling. The part of tooling that is limiting you in this instance is their webpack configuration, which is preset to only look for javascript files in your src directory.
That explains the why? but to answer the other half of your question:
how can I disable it?
Is that you would need to eject from Create React App and then modify your webpack config to allow it to search directories other than src/
First - this has nothing to do with react itself.
If you refer to importing javascript modules (for now using module loaders like systemjs, require, etc.) then the answer is:
It depends what directory is being served by web server. If you have set up your web server to serve WebApp/src folder only - then no, browser will not be able to get access to the files outside and so module loaders. If you will serve all ProjectRoot directory - then yes, you can.
If you prepare your web application for deployment using some sort of bundlers (webpack, browserify) - it depends on how you will configure them and instruct to include the required files in the resulting bundle.
I'm trying to use webpack with my angular-meteor application. Unfortunately the meteor build fails with the following error:
While determining active plugins:
error: conflict: two packages included in the app (pbastowski:angular-babel and webpack:webpack) are both trying to handle *.js
The angular-meteor package has a dependency on pbastowski:angular-babel for ES2015 support, while webpack uses the babel-loader. Any idea how I can avoid this conflict?
This is a Meteor message that will appear when two Meteor packages try to add a Meteor compiler plugin for the same file extension, in this case ".js".
Option 1
Remove webpack:webpack from your project. Do you really need webpack in your Meteor project? Meteor bundles everything for you, so, there is no need to use webpack, as such. If you want to use ES6 modules then consider using pbastowski:systemjs.
meteor remove webpack:webpack
I don't know your reasons for using webpack, but I thought I'd mention this option.
Option 2
You can configure pbastowski:angular-babel to not compile ".js" files by adding the line below to babel.json in your Meteor project's root folder. However, if you do this, Babel will only compile ".es6.js" files and not ".js" files.
babel.json
{
"extensions": ["es6.js"]
}
Some people here are trying to say that Webpack is useless but they really don't know much about it.
It can helps you bundle a lot better your assets.
You can bundle better your CSS and even have local CSS (css that is not applied globally but only in a section of your page)
You can do code splitting and not serve your entire app on the first page load
You can have hot-reloading with no page refresh (at least with React ;))
You can use angular and Webpack together without any problem. Here is what you need to do:
meteor remove angular
meteor add angular-meteor-data
meteor add angular-templates
The only missing piece then is ng-annotate and luckily, there is a few ways. You can use the ng-annotate-loader or ng-annotate-webpack-plugin in your Webpack config file.
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.