@adamdbradley I think you closed #3 in a rush.
angularfire2 and firebase are something you can't ignore when thinking ionic...
It's also not specific to them, it's a problem when using rollup, I think the rollup process needs to handle commonJS directories transparently.
I now have another, similar error with lodash
When I:
import { assign } from 'lodash';
I get:
[14:02:04] bundle failed: Error: Module /app/node_modules/lodash/lodash.js does not export assign (imported by /app/.tmp/data-source/some.service.js)
Again, there is a workaround but ionic developer shouldn't get hard time on simple tasks:
import assign from 'lodash/assign';
This is not perfect, there is a TS error:
[14:14:40] src/data-source/feeding.service.ts(5,8): error TS1192: Module '"lodash/assign"' has no default export.
There's a switch in error between the 2, when TS is happy rollup isn't and vice versa.
BTW, rollup does a wired thing when doing:
import * as assign from 'lodash/assign';
assign will be the module, with a default property which is the assign function...
error_handler.js:45 EXCEPTION: Error in ./HomePage class HomePage - inline template:17:10 caused by: assign$2 is not a function
I know you considered #3 as someone else's problem but app-scripts is part of the ionic CLI and if the integration is not smooth you'll get ton's of complaints.
If you integrate rollup you need it to be transparent.
Hi @shlomiassaf,
We're not sure what you mean. We do support commonjs as we are using the latest version of the commonjs plugin.
https://github.com/driftyco/ionic-app-scripts/blob/master/config/rollup.config.js#L37
Please let me know if this fixes your issue. I'll re-open if needed.
Thanks,
Dan
@danbucholtz Why did you close the issue? is this a common behaviour for people contributing to your project? You didn't solve it...
Now, before you run and close try to look into the issue.
I kindly ask you to try and integrate angularfire2 or lodash.
I'm trying to save you a lot of time and complaints later on, I'v spent a lot of hours on this beta, this is not how you should treat people who try to help.
This is insulting
Jus to clarify, the reason I react like that is that the same error was closed in #3 without a solution...
Here's another issue for you:
In watch mode when using skip property in the nodeModules plugin for rollup (within rollup.config.js) the skip is only valid for the first run.
Save something and the next update will error since using cache for rollup causes an issue.
If you disable caching everything is fine, but you can't do that without changing the code of this lib.
I'v managed to workaround the angularfire issue and now this cache thing you introduced broke it...
I know sometime people pollute the issues but this is not the case, anyone who could use the beta.12 without docs should be taken seriously, its across 4 repos of integration.
Hi,
I am seeing an issue here. I'll look into it. The goal is the user doesn't need to care if a 3rd party lib is commonjs or es2015 modules.
Thanks,
Dan
I know it's the goal and I also now that you'll get tons of complaints for these 2 libs only...
I'm trying to help.
@shlomiassaf we're looking into it and taking it seriously. This needs to Just Work or it won't be acceptable on our end. Apologies for the confusion.
@danbucholtz @mlynch This is really a core issue with the rollup bundling process.
I can't import major libraries.
Now moment is giving me hard time, see this issue comment, I can run in dev but I can't build to a device.
BTW, I had to use moment since the Intl polyfil is not present so iOS safari can't run angular 2 if for example i'll use the date pipe.
Hi @shlomiassaf,
We are aware of this issue and working on it. I don't have more to share right now but I hope to soon.
Thanks,
Dan
Hi @shlomiassaf,
I have successfully created a project with moment, lodash, node-uuid, localforage. All commonjs modules. You're right there is an issue here. I've come up with a solution. I'll have more details on it tomorrow.
In the meantime, the code changes to app-scripts to facilitate it are here:
https://github.com/driftyco/ionic-app-scripts/pull/29
Thanks,
Dan
@danbucholtz thanks!
I couldn't load moment via
import * as moment from 'moment'
I had to use default syntax:
import moment from 'moment'
This requires
"allowSyntheticDefaultImports": true,
in tsconfig.json
Problem is i'm getting a new error now, in runtime...
I'm pretty sure it's not related to your change but if you have clues it will be great
EXCEPTION: Error in ./IonicApp class IonicApp - inline template:0:34 caused by: No provider for ParamDecorator!ErrorHandler.handleError @ error_handler.js:45
error_handler.js:47ORIGINAL EXCEPTION: No provider for ParamDecorator!ErrorHandler.handleError @ error_handler.js:47
@shlomiassaf,
Nice find with the allowSyntheticDefaultImports option. I'll play around with it - this sounds like the secret sauce that we need to make things work the way we want!
I'll have an update coming soon.
Thanks,
Dan
@shlomiassaf!
That option is working great so far!
Thanks,
Dan
I made my sample project public. Check it out.
https://github.com/driftyco/ionic-third-party-lib-example
Thanks,
Dan
@danbucholtz Thanks! great progress.
It looks like the bundling issue is solved.
The cache issue is still there.
The node UUID lib uses the 3rd partycrypto library that rollup treats as external dependency.
On the first run everything is fine but any code update done in watch mode will result in an error:
[21:23:35] Error: Could not load crypto (imported by /Users/shlomiassaf/Desktop/Cisco/IONIC/ionic-third-party-lib-example/node_modules/node-uuid/uuid.js): ENOENT: no such file or directory, open 'crypto'
If we disable caching of the rollup bundle by commenting out this line code update works without a problem.
So, the problem is that caching somehow does not respect previous configuration.
For me this happened when using firebase as external module via the nodeModules plugin in rollup:
nodeResolve({
module: true,
jsnext: true,
main: true,
browser: true,
extensions: ['.js'],
skip: [ 'firebase' ]
})
@danbucholtz, still can't use angularfire2
@danbucholtz keep an eye on angular/angularfire2#565
Hi @danbucholtz,
I am facing similar issues over using external libraries like lodash.. I tried cloning the project you linked earlier (https://github.com/driftyco/ionic-third-party-lib-example).. The application runs and the libraries seem to work fine.. But in my IDE (SublimeText), I'm getting the following issues:
ts file: Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option to remove this warning.Module "....../ionic-third-party-lib-example/node_modules/moment/moment" has no default export. In addition, IDE autocomplete for these library symbols is not working..It seems to me I'm doing something stupid and overlooking something simple.. Could you please help in this regard?
I'm thinking the sublime plugin you're using likely does not support the latest major version of Typescript (2.0). Give vscode a shot, it is maintained by Microsoft so it works incredibly well with Typescript.
Thanks,
Dan
@awe-sim As a rule of thumb I always check console errors when running the complication and only then take the IDE errors seriously. No error in console, no issue.
It's hard for IDE plugins to keep up when changes are so often :)
@danbucholtz .. Thanks for pointing the issue out.. Yes the sublime plugin supported typescript v <2.0.. Using VSCODE now and its working good.. Thanks a lot.. =)
@shlomiassaf, any leads on what's going on with AngularFire? Sounds like they may use a dependency that rollup can't handle? We may need to make WebPack an option if Rollup can't handle all libs. That would be unfortunate as performance would suffer.
Thanks,
Dan
I'm also having a similar issue with moment-timezone. I would _love it_ if you guys reverted to webpack until rollup is more seriously vetted. The collective amount of time the community has wasted battling with this new build system is a rough indictment of the quality of this release. That, coupled with the general confusion on importing styles, iOS build failures with ionic package, et al... is just not consistent with the quality you guys typically ship with :/
Sorry to rant here, as I know it's not the place; it's just be a super frustrating 48 hours trying to migrate my beta11 project to rc0.
@danbucholtz I think you should have a talk with the firebase guys.
I'm not sure the issue is with the rollup build process, and if it is it's unique to the firebase build...
Just to recap I will sum up...
There are 2 issues, one related to firebase the other is not.
It should be noted that this happens when firebase is imported from angularfire2 I have not checked what happens if we omit angularfire2 and try to import firebase alone.
@danbucholtz This should hint, if you can go with firebase without angularfire2 you should go to the angularfire2 guys and vice versa :)
To workaround for now see this issue comment
skip option in rollup-plugin-node-resolveBasically I used skip to workaround the firebase issue.
The problem is the cache bundle implemented in the bundle process, when cache is disabled there is no issue. When cache is enabled 1st compilation works fine but when updating the code rollup throws that he can't find firebase
Hope it helps, Thanks.
@mlynch & @danbucholtz About your note, moving to Webpack instead of Rollup.
I think it is the right place to go to and should have been used from the start.
ionic-angular will live there.There are lot's of other reasons, really so many.
the app-scripts package is trying to implement things webpack does and does great!
I don't see any benefit of using a custom rollup procces when it's clear that the direction of the community (at least angular) is webpack.
Why spending the time exploring lazy loading with your custom process or caching or any other issue when Webpack has it already baked in and if not the angular cli team has probably tackled it and solved it...
The angular team is going to release a lot of tools used by the Angular CLI as decoupled webpack plugins (see npm namespace @ngtools), this is what they said in angular connect.
I really thing you should reconsider and move to webpack.
BTW: My angular 2 library is using webpack for development and Rollup for UMD bundling so I can deploy an AOT ready library and an ES5 (UMD) library... It's possible to integrate the 2
@shlomiassaf,
Don't use skip, used named exports to get Firebase working. What we need here is documentation. We've been able to get every library working with Rollup that we've tried, sometimes it has just taken a little configuration using named exports since the plugins have some weird dependency or weird way of exporting data that Rollup can't quite figure out.
Webpack is a nice tool but start-up time will be 2-3x slower from our tests. Do we sacrifice speed for everyone for the subset of people that use commonjs libs? I'm honestly not sure. This question has weighed heavily for me for a few days now.
Thanks,
Dan
Hey @danbucholtz I got a big production app updated to RC0 with Firebase 3 and AF2, took me a while but I got it working following this tutorial https://playcode.org/getting-started-with-ionic-2-rc0-firebase-3-angularfire-2/
Also, whenever I want to use the regular JS SDK instead of doing:
import * as firebase from 'firebase'
I just do declare var firebase
Before the @Component declaration and it works so I think you guys could look into a solution incorporating this instead of going back to webpack.
Thanks for the tip @javebratt!
@danbucholtz, documentation/blog post will really help. Since you folks have been able to get most of the libraries working, I think it can save community some time figuring out things.
I faced issues with katex, providing named exports solved the issue. for me, one of the recent rollup optimizations seems to be causing problems, https://github.com/rollup/rollup-plugin-commonjs/issues/115.
Was also facing issues with mathjs apparently related to node's built-ins.
@pskhodad,
That may explain why things were "working better" for me a few weeks ago in earlier testing of Rollup. I was running my own custom branch of 4.x with the unambiguous grammar fix in. Thanks for pointing this out to us!
Thanks,
Dan
Hi
My two cents on this.
I have been updating my own app as well using various libraries some not the most common e.g:
and a couple of others.
I must agree with @shlomiassaf there are a large number of issues with the move to rollup. I have this feeling right now most people are "hacking" libs or the config to get things working - almost a trial and error.
My rollup config file looks like a mess with all the 'named' libs i have had to add in and also the amount of libs i have had to manually add into index.html + assets folder.
I understand there are benefits of rollup but i feel we have jumped the gun a little on it and maybe those benefits are not going to be realised by the large majority of users at this point because of the challenges to hack things together.
Hope your blog post comes soon because after two days of hacking away at various imports and rollup config settings i am going at the point of defeat!
There are couple of suggestions by @nolanlawson described in https://github.com/driftyco/ionic/issues/8356.
I guess this can provide best of both worlds,
"using Rollup in a very limited way (to produce a small CJS bundle), and then following up with Webpack/Browserify."
"Another possibility would be for the ionic-app-scripts to include a small whitelist of modules that are known to play nice with Rollup, and then use Browserify/Webpack for the rest."
@danbucholtz when you say 2-3x slower startup, any idea why this is? Maybe with some configuration web pack can achieve the same results and being more "compatible", maybe it makes sense to invest in that instead of investing in rollup to play nice with everything. We have a lot to gain from webpack's popularity especially since it is being widely used in angular2.
@masimakopoulos, Webpack is slower because it doesn't hoist all dependencies into the same scope. Long story short, each dependency is in it's own closure with WebPack/Browserify.
Nolan Lawson, a good friend of Ionic and PouchDB dev, wrote a great article on the subject. It's essential reading in my opinion.
https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/
The article shows not only the reduced bundle size of using something like Rollup, but also the performance improvement and startup time improvement.
We are not ruling out Webpack completely, but we're going to stick with Rollup for now. That's not to say the community couldn't create a Webpack config that others use, it's just not something we're going to pursue at this time. FWIW, we consulted with the Angular team before settling on Rollup.
Thanks,
Dan
@danbucholtz Will this repo ever support Webpack? i've been using it since alpha.43 and my project is basically binded to webpack at this point, changing to Rollup would mean scrapping up all my bundling pipeline so far and start learning Rollup, which basically means lots of time and effort will have to be invested in that process.
I honestly think it should be up to the developer which bundle tool to use, may ionic promote Rollup as the recommended way, but allow the developer the option to chose Webpack.
Is there a way for me to stick with Webpack right now with RC.0?
Also if i recall the beta.11 announcement in the Build Process Improvements section it says ionic would migrate to Webpack 2, isn't this the ionic blog?
@Luchillo From a developer point experience should be constant, so if Rollup is the choice it should be fully functional and high quality so I think getting there is more important then supporting 2 build systems.
Once the Rollup CLI is stable I think a webpack solution might come up... I agree with @danbucholtz on that.
I also believe the Webpack team will go towards performance improvements, at least getting close to rollup as much as possible but this will take some time.
@danbucholtz I solved all issues raised here with the new RC and the suggested solutions (named exports). I must admit, its not trivial and requires custom configurations which is a blocker for a lot of developers and will make them spend a lot of time on strange 3rd part integrations issues.
I think we can close this, maybe you can open a webpack issue for people to discuss...
Please close if you agree :)
Not sure it makes sense to close this as I don't think using named exports in a config file that's loaded in the node_modules directory is a valid fix for this. I would hope there is a better outcome that doesn't involve modding config files on a case by case basis every time we add a new library to our project.
@henry74 I agree with you. If we have to have a custom config for every single library, then rollup is not the right approach. However, what we're seeing is that many libraries have moved to the new, _standard_ module format so they Just Work without you having to do anything. Additionally, many commonjs modules do work without extra configuration with default rollup plugins we're adding to app scripts by default. However, it's a few, admittedly important libraries, that get a bit too clever about their modules that make it difficult for rollup to understand them. For those, we have ways to make them work today until they move to the new standard.
The way we look at it is, if es2015 is the standard approach, shouldn't we pick it going forward? We'll assume that the most popular, highly used libraries, will soon adopt it if they haven't already. For those that don't, we have ways to make it work, and we're continuing to add more plugins and configs out of the box for rollup so you don't have to have a custom config.
I know it sucks in many ways, but it's not about rollup vs webpack, it's about a standard module format that the industry is adopting as we speak, vs custom ones that will be irrelevant much the way coffeescript is now that we have ES6 :D
We gain a lot of awesome benefits by having a standard module format that rollup can efficiently bundle, especially when we consider progressive web apps where loading a 2MB bundle file is just not acceptable (this is what we were seeing with webpack, along with noticeably slower boot times and time-to-first-render). Ionic developers keep asking us for faster apps and better performance. Well, this part of the runtime is _really important_ for performance and perception of performance.
Anyways, that's the counter argument here that many Ionic team members believe in. It's not a universal opinion on the team, though, and even I have misgivings about it. However, in my testing, I've found that many if not most/all modules I've tested work fine, so I don't know.
That's my mini rant for the night :D
@Luchillo,
You're free to use Webpack but we won't actively support you, have docs, etc. I am confident the community will create some solid options here. At this time, we are sticking with Rollup.
Yes, we did say we were going to go with Webpack 2. We weighed the pros and cons and settled on Rollup.
Thanks,
Dan
To add to what @danbucholtz said, the way we built all of this is that you can use other bundlers if you want. It won't be the official way, but you're entirely free to have any kind of script or build chain you want. If your code compiles and runs, that's all that matters if you're okay with the tradeoffs for your tool of choice!
@danbucholtz Ok Rollup it is, so if i would like to stick for the time being with Webpack i wouldn't be able to make use of ionic-app-scripts? would i have to provide both the live reloading for ionic serve as well as the compiling that ionic run <platform> does after the JS build?
@shlomiassaf
BTW: My angular 2 library is using webpack for development and Rollup for UMD bundling so I can deploy an AOT ready library and an ES5 (UMD) library... It's possible to integrate the 2
I'm just doing dev, learning ionic2 + angular2 right now, and fast debugging with ts source maps is far more important to me than than a compact deployment. I jumped directly from gulp so webpack is still new to me. Can you (or someone else) share a webpack config that works with the RC0 build process for dev?
@mlynch I see your point and sounds the way forward. Can we have some documentation for libraries that do not work out of the box with rollup today, on how we can make them work, so that we don't have to go through ten's of closed issues to find the solution each time? For instance I am trying to use pouchdb with my project but I am getting an error, I know it has been solved in some issue, but I think, given the popularity of the library, it would make sense to be more readily available.
@mixersoft I'm with you about wanting a webpack example working with RC.0.
However in my case this is a little more complex, i already have an app in the Play Store and IOS store, so i really would like to stick with what i already know (Webpack) instead of figuring out Rollup quirks.
@masimakopoulos,
I am writing that documentation as we speak. Expect for it to be posted today.
Thanks,
Dan
@danbucholtz awesome. Please add a link here when you are done.
Also @shlomiassaf could you fix the typo in the title so it can be found more easily in the future?
I gotchu
@masimakopoulos,
It is looking like it may be one more day on the docs. I am doing a deep dive into the various issues and how to configure Rollup to circumvent them.
Thanks,
Dan
All,
What other libs are people having troubles with? I am trying to understand the breadth of the issues so I can document them well and come up with solutions.
Here's how you import Moment.
import moment from 'moment'
@shlomiassaf,
Here's an Angularfire2 sample. Angularfire2 was not really any different of a solution than the pouchdb or some of the other commonjs libs where a deep dependency (not the lib itself) is getting clever with module.exports. Using namedExport options in the rollup config is the solution for now. We will very likely come up with a better solution in time. See the example here.
It is really easy to override the rollup config. We just did not do nearly a good enough job of documenting it. That is 110% on us. We really dropped the ball there and are working to resolve the issue by generating quality docs as we speak.
@mixersoft,
We are tracking the source map issue here.
Thanks,
Dan
The one that I need in particular is moment-timezone... It looks like this has been resolved with the latest ionic-app-scripts changes, but it may still be worth mentioning in the documentation you're working on.
Thanks for doing this by the way! We definitely need it :)
@mlynch was able to get moment-timezone to work if I remember correctly.
I will add it to my list of libs to create a sample for.
Thanks,
Dan
@danbucholtz moment-timezone for me was actually a typescript error. It adds ts to the Moment object and for some reason TS didn't like that. Curious to see how you got it working without (myMoment as any).tz
@mlynch I also got it working in same way (moment as any).tz
@aggarwalankush,
Yep. This isn't a hack, this makes sense in the Typescript world. I don't think there's a notion of type definition extension, so the moment instance is still typed according to the moment type definition.
If you don't want to use the as any, one could use an implicit any shorthand module declaration in a declarations.d.ts file that looked like this:
declare module 'moment';
declare module 'moment-timezone';
Thanks,
Dan
@danbucholtz Yes this is not a hack and it's just typing so doesn't matter much also. But that declarations.d.ts file seems interesting. Should I put it in root directory of project?
I always put it in src. It is pretty great. I use them occasionally for libraries that don't have type definitions.
When you import moment from 'moment', moment has an implicit any type then. It's pretty nice and flexible.
@danbucholtz Thanks for writing a doc on external library usage. With the Ionic 2 beta releases I had also problems with Chart.js ([http://www.chartjs.org/]) and ended up with a quick-and-dirty load in index.html. I could not test it with RC0 until now, because I am still struggling to get PouchDB started, which was fine in the Betas... For now, I will stop with this Ionic 2 project and wait until third party libs are more easily loaded into Ionic 2.
I have problem with angular-in-memory-web-api: https://github.com/angular/in-memory-web-api/issues/42
All,
We've posted some docs on the subject. Note: They match a version of @ionic/app-scripts that will be dropped in the next day or so. 95% of the concepts still apply.
http://ionicframework.com/docs/v2/resources/third-party-libs/
http://ionicframework.com/docs/v2/resources/app-scripts/
Here's an example with AngularFire2.
Here is a project I implemented that has most libraries in it that Ionic users have reported trouble with. Most of the libraries worked, but a couple did not. Here is the summary of the findings.
Please let me know how everything goes. I'm going to close this issue for now as we've shipped the documentation.
Thanks,
Dan
@danbucholtz i'm seeing you have that example with lodash, however what about lodash modules?
Say i'm importing it like this:
import { map, reduce } from 'lodash';
Then the freaking cli complains:
bundle dev failed: Module /home/carlos/Carlos/OSGroup/startApp/node_modules/lodash/lodash.js does not export map (imported by /home/carlos/Carlos/OSGroup/startApp/src/providers/db.ts)
[12:27:34] Error: Module /home/carlos/Carlos/OSGroup/startApp/node_modules/lodash/lodash.js does not export map (imported by /home/carlos/Carlos/OSGroup/startApp/src/providers/db.ts)
This was working with my Webpack setup right before i started transitioning to Rollup.
Try this:
import _ from "lodash";
_.map(...)
Some of the imports have to be modified to work with Rollup.
@Luchillo,
@Kobzol is correct. If it's a third party module, it's best to just import the whole thing for now since most are commonjs. See our docs on third party libraries here.
Thanks,
Dan
@shlomiassaf, you figure out the cache thing? I am trying to come up with a solution for it right now.
Thanks,
Dan
@Kobzol Yes i know that can be done, the objective of importing the individual modules was to limit the size of the lodash import, maybe three shaking takes care of it, idk but still this should work.
@danbucholtz for the time being i'm going to import the full lodash lib, is there any issue to track about those kind of sub-modules with Rollup or this repo?
@Luchillo,
You're importing the entire lodash lib anyway because it it is a commonjs module. Commonjs modules aren't tree shakable.
If you want everything to just work nicely, lodash-es is the es2015 version. See link here.
In general, if a named export like this import { capitalize } from 'lodash'isn't "just working" out of the box, you're importing the entire library whether you want to or not.
The JS community is right on the verge of a massive shift from commonjs to go all in on the standard ES2015 modules. Once Node adopts it, which they are committed to and soon, it will be game on and ES2015 will be off the races.
We just need to get through the next few months to get there.
Thanks,
Dan
Ok so lodash-es is the next version, does it works with sub-modules (or however it is called)?
Also i don't see the @types for lodash-es, will the regular ones work?
Ok no type definitions, but at least i just had to find->replace the imports in 27 files on my project, i can't begin to imagine how many places would i have to go and change manually without lodash-es.
Now here start my hell, i had a whole range of libs in my Webpack config, how am i supposed to import this libs or their equivalent in Rollup?:
I also have 1 custom font i need to copy/paste, is that in the assets folder?
@Luchillo,
I don't think your code will have to change much at all. For the most part, anything that was like this:
import * as something from 'someLib'
should become:
import something from 'someLib'
If the fonts go into a folder in assets it will automatically be copied over.
Thanks,
Dan
Ok that leaves moment, lodash, ng2-charts all green.
However intl, web-animations-js were called in a polyfills.ts file and in webpack was a separate entry, how would i do the same in Rollup, do i have to make a Rollup config file?
My webpack config used the ProvidePlugin to provide chart.js, signature_pad and comparev as global scope, just like an html script tag would load those libs, how to in Rollup?
Lastly i need to define a variable, what i do is to require the package.json, then use the version attribute to set the VERSION variable in the app's global scope with webpack's ProvidePlugin, Rollup?
May i need to copy rollup.config.js and start hacking?
@Luchillo,
Here is the documentation on customizing the build process. So far we only have it populated for bundling, which is what you'll want.
http://ionicframework.com/docs/v2/resources/app-scripts/
Thanks,
Dan
@danbucholtz So i started editing my Rollup config, it compiles with only a few warnings about unused vars, however in browser this error pop's in console:
Uncaught ReferenceError: IntlPolyfill is not defined
Which i've tested and it has an error with my polyfills that i'm trying to import in app.module,ts as:
import './polyfills';
I've tested commenting the imports in that file and error changes depending the lib that is first in the file, if i comment intl, then web-animations-js polyfill breaks, so this is not the way to import polyfills?
@Luchillo,
Maybe it is best to create a post on the Ionic forum. We're happy to help but I'm not sure this is the correct medium with all of the other subscribers.
I would need to see your code to help further. I don't have the necessary context.
Thanks,
Dan
Yes, i already have, however the response time of anyone that can really help in this new issues is close to 2+ weeks, here's the post, it has more context about how am i trying to import, i don't think is that complex to reason about: https://forum.ionicframework.com/t/how-to-rollup-pollyfils/66108
Hey folks, I have a couple projects with this setup so I created a post about how to get it working. Not ideal, but until the Firebase team updates their code base it's the best I could do.
http://alexmgrant.github.io/ionic/firebase/rc0/lodash/2016/10/06/ionic-rc0-&-firebase.html
@danbucholtz I'm having issues with ImmutableJS, getting a .../immutable.js does not export fromJS error on build. Any advice?
I was able to import and use immutable. If you want to use namedExports like fromJS, you'll need to provide a custom Rollup config as Immutable is not distributed as a modern/standard ES2015 library despite being written as one.
See here for an example, and see our docs on third party libs here.
See the bundle section here.
Thanks,
Dan
I'm having trouble using d3 and d3-request specifically.
According to Mike Bostock the bundle process "is not importing the code from the ES2015 source, per the module (and jsnext:main) entry point defined in the package.json. Instead it appears to be pulling from the generated UMD bundle"
If anyone could help me resolve this, there's a 100 bounty on my stackoverflow question which I'm almost certain is related to this issue.
http://stackoverflow.com/questions/39909200/d3-4-0-import-statement-gives-moduleexports-wrapper
@parliament718,
d3 has a strange default export, so I had to use the full module import syntax. It is important to note that in this case, d3 is a "wrapper" object that follows the es2015 standard. It is an object containing reference to all of the exports. d3.default would be the default export for example.
import * as d3 from 'd3';
console.log('d3: ', d3);
The log statement should reveal what fields it has and the docs should reveal how to use them.
We are definitely importing the code from module, then jsnext:main, then main in that order.
Thanks,
Dan
Hello all,
Just as a follow up, we have a PR open right now adding Webpack support. Webpack 2 beta has come a long way and the start-up time gap is not nearly as long as it once was.
Hopefully this will be released sometime next week.
Thanks,
Dan
@danbucholtz Man i'm glad to hear that, i'll be the first (or at least i'll try) to implement it when the PR get's merged.
@danbucholtz I checked all the links and also your mega test. I am trying to use https://github.com/videogular/videogular2
The instructions to install and use it are here:
https://github.com/videogular/videogular2/blob/master/docs/getting-started.md
It already runs in Angular 2 using TypeScript.
This is used for videos on iOS. I just want to show video on autoplay on iOS and am not able to find a native plugin, so thought I would integrate videogular2. But I a not able to do so. Can you please take a look at this too?
Thanks
I have same issues.
Ionic bundles succesfully in case of 'out of the box' but customizing is painful.
I found not documented --dev flag which only ables development build for ionic run.
Rollup still has lot of issues with external libraries. I cannot understand why it was choosen.
I tried to use webpack with Ionic2RC1 in my project.
I even tried to build Ionic2 from sources but I've met runtime error
Uncaught Error: Can't resolve all parameters for provideLocationStrategy: (PlatformLocation, ?, Config).
Webpack has code-splitting and CommonChuncks plugin which significaly improve development performance.
e.g
~700ms watch-rebuild for Webpack
~7s watch-rebuild for Rollup
It is not a bundling tool now. It is tusk runner, for every job you lazy to do manually, from bundling application with webpack or any other bundler to signing android release APK and opening Xcode.
@Dan: Thanks for adding webpack support. I am eagerly waiting for this support :-)
Current I am seeing issue as mentioned below:-
`
18 10 2016 22:04:35.664:INFO [karma]: Karma v0.13.22 server started at http://localhost:9876/
18 10 2016 22:04:35.674:INFO [launcher]: Starting browser Chrome
18 10 2016 22:04:37.638:INFO [Chrome 53.0.2785 (Mac OS X 10.12.0)]: Connected on socket cZvudWwQ4tXebfJvAAAA with id 5405126
Chrome 53.0.2785 (Mac OS X 10.12.0) ERROR
Uncaught Error: Cannot find module "./data/packed/latest.json"
at /Users/gyana/Sites/gyana-ai/tests.webpack.js:49281 <- webpack:///~/moment-timezone/index.js:2:0
Chrome 53.0.2785 (Mac OS X 10.12.0) ERROR
Uncaught Error: Cannot find module "./data/packed/latest.json"
at /Users/gyana/Sites/gyana-ai/tests.webpack.js:49281 <- webpack:///~/moment-timezone/index.js:2:0
Chrome 53.0.2785 (Mac OS X 10.12.0): Executed 0 of 0 ERROR (0.7 secs / 0 secs)
Finished in 0.7 secs / 0 secs
`
I assume this will be addressed with your webpack support to moment-timezone?
Thanks,
Deepak.
We have entered a beta testing phase with Webpack.
Please see this post if interested in testing.
https://forum.ionicframework.com/t/help-us-test-webpack-support-in-ionic-2-app-scripts/67507
Specifically, we're looking for library incompatibility and additional loaders we may need to add. We are working on improving the performance of the builds, too.
We are only using Webpack as a javascript bundler - not as the development server, other asset bundler, etc. We intend to support Rollup going forward as well.
Thanks,
Dan
Most helpful comment
@mlynch & @danbucholtz About your note, moving to Webpack instead of Rollup.
I think it is the right place to go to and should have been used from the start.
ionic-angularwill live there.There are lot's of other reasons, really so many.
the
app-scriptspackage is trying to implement things webpack does and does great!I don't see any benefit of using a custom rollup procces when it's clear that the direction of the community (at least angular) is webpack.
The angular team is going to release a lot of tools used by the Angular CLI as decoupled webpack plugins (see npm namespace
@ngtools), this is what they said in angular connect.I really thing you should reconsider and move to webpack.
BTW: My angular 2 library is using webpack for development and Rollup for UMD bundling so I can deploy an AOT ready library and an ES5 (UMD) library... It's possible to integrate the 2