When we released RC0 release with our new App Scripts build tools and a new bundle process using Rollup instead of Webpack (for performance reasons), we received a ton of feedback that you really wished you could use Webpack instead of Rollup. The Webpack ecosystem is larger, many of you have created complicated webpack configs, and Webpack plays more nicely with the plethora of commonjs modules that haven’t moved to the ESM module standard.
Well, we’ve heard you, and we’re excited to release a beta version of app-scripts that uses Webpack by default. If you’re happy with Rollup, then you can ignore this: our tool will continue to use rollup if you have a custom rollup config. If you’d like to read more about customizing the bundle process, read our docs on customizing your build config
To help us test, install the beta tag of ionic-app-scripts in your Ionic 2 app directory:
npm install @ionic/app-scripts@beta
Then run npm run build to test the new build process.
Please let us know if you have any feedback. We are strongly considering moving to Webpack as the default so your feedback and help are greatly appreciated!
Do you have an example of a working custom config? I tried starting with the stock one in node_modules/@ionic/app-scripts/config, and had many silent build failures. I had to switch to using ts-loader instead of the ionic-loader, and explicitly excluding main.prod.ts in tsconfig.json.
I just created a new app and installed beta version of app-scripts.
After that I installed Firebase, imported it in app.component.ts created a firebase.auth().onAuthStateChange() function and it’s working by default, didn’t have to do anything else, nothing broke, it just read the auth state and returned the correct value.
While possible to do, we don’t recommend doing that at this time. The build process is pretty rigidly defined (we’ll make it more customizable in the future), so there isn’t a lot of value in it anyway.
Can you open an issue here with details about the troubles you’re experiencing? So far we’ve had good results with our stock config, so we’d like to understand what’s issue you’re encountering and fix it. In general, we don’t think it is a good idea to customize Webpack just yet because the configuration is very tightly coupled to the rest of the build process we have in place.
Here are a few details about the Webpack process as it stands now:
We’re only using Webpack for bundling Javascript. It does not compile the Typescript, or process the sass, copy files, etc. We feel strongly that this is the path forward if we want to stay future proof and support multiple tools. Webpack is very popular right now, but there will inevitably be a newer, better tool coming down the road. We really like some of the speed benefits that Rollup brings to apps, so we are going to keep support for that in place and help push the community adoption as much as we can.
The Typescript code is compiled to Javascript before the Webpack portion of the build process starts. It does some clever tricks to load the Javascript files from memory instead of the hard disk to make the bundling process faster. We are continuing to iterate on the bundling process to make it faster.
We’re not using the Webpack Dev Server because we want to provide our own developer experience. We have some really cool things planned to make troubleshooting Ionic apps a great experience.
We’re excited about @ionic/app-scripts. It started out a little rough but it has gotten much better. We personally really believe in Rollup, but we recognize that the community is just not there yet. We have some really good stuff planned for app-scripts, and making it more flexible/configurable is on the roadmap.
Please feel free to reach out to me with any questions. This is an open offer to any Ionic community member . I’m happy to explain our rationale and help.
You make a good point, however introducing a new “new” thing just because it’s newer and better seems like a cost that outweighs the benefit. Especially with webpack 2 which looks to me to be very similar to what rollup does but piggy backs on what people have already taken the time to learn.
Again, sounds great. But keep in mind that if people are choosing Ionic it’s probably because it uses Angular 2. The Angular CLI project looks to be the most dominant way to scaffold/run angular apps. Yes there are advantages to having a custom CLI with unique tools, but again I would venture to say most people are using ionic because of angular, not angular because of Ionic. It just keeps things simpler to use what people are already using to build angular apps rather than having to learn a totally new tool. One new tool quickly becomes 5 or 10.
I think the overall thing that I see again and again referring to “Javascript Fatigue” is the problem that yes, there will always be a better tool down the road, but it’s exhausting to constantly change paradigms rather than improve ones that we already have. @danbucholtz Not trying to be a jerk, just wanted to give perspective from a guy who bounces around between tools all day and feels like he can never get his head above water before the next wave comes crashing down.
As an aside I was trying to get webpack working so I could get a testing suite set up. I couldn’t find any documentation about how to setup unit testing with Ionic2 & typescript. Am I missing it? Having that somewhere would be a HUGE win that would end up saving me what I imagine to become 2 days of banging my head against the wall.
I’m not sure if this really related, but there’s issue with livereload even after 2.0RC1. In my case, the watch is not triggered even after supplying the “-l” option into ionic run. I managed to work around it by forcefully adding the watch task into run:before scripts list in package.json.
This works fine while using rollup. But after trying webpack, it failed during build process. It got stuck somewhere after completing the build task, which is expected,i guess.
[12:27:20] ionic-app-scripts 0.0.37
[12:27:20] watch started ...
[12:27:20] build dev started ...
[12:27:20] clean started ...
[12:27:20] clean finished in 5 ms
[12:27:20] copy started ...
[12:27:20] transpile started ...
[12:27:20] lint started ...
[12:27:23] lint finished in 3.23 s
[12:27:24] transpile finished in 4.55 s
[12:27:24] webpack started ...
[12:27:25] copy finished in 5.34 s
[12:27:32] webpack finished in 7.56 s
[12:27:32] sass started ...
[12:27:33] sass finished in 1.29 s
[12:27:33] build dev finished in 13.41 s
The reload speed with 0.0.37 and webpack seems about the same as with rollup, i.e. it takes ~5 seconds on my machine after changing some typescript code. I guess it’s using webpack but not the webpack-dev-server?
I started with Ionic because of Angular. But today I stayed with Angular because of Ionic. But I agree with you. With two different bundle stacks is worse for the community maintain support.
When I tried to use a custom webpack config I got some errors. The config was the same of ionic-app-scripts, but didn’t work.
[00:06:02] ionic-app-scripts 0.0.37
[00:06:03] build prod started ...
[00:06:03] clean started ...
[00:06:03] clean finished in 3 ms
[00:06:03] copy started ...
[00:06:03] ngc started ...
[00:06:03] copy finished in 223 ms
[00:06:03] lint started ...
[00:06:06] lint finished in 3.04 s
[00:06:22] ngc finished in 19.09 s
[00:06:22] webpack started ...
[00:06:22] webpack finished in 72 ms
[00:06:22] uglifyjs started ...
[00:06:22] sass started ...
[00:06:22] uglifyjs failed: ENOENT: no such file or directory, open
'/Users/helabs/Jean/miniReceitasRC1/www/build/main.js'
[00:06:22] ionic-app-script task: "build"
[00:06:22] Error: ENOENT: no such file or directory, open '/Users/helabs/Jean/miniReceitasRC1/www/build/main.js'
@soupman99, we will be introducing unit testing support into app-scripts. It’ll be a bit but it is medium to high priority for us.
As for the rest, I understand your concerns but that is the path we are taking. This is very similar to the path Angular is taking with the CLI. If you start modifying the Webpack config, there is a very good chance it won’t work and you won’t be supported. Our goal is to have a cohesive, easy-to-use, and easy-to-hook-into system.
We don’t recommend using the -l flag right now. It is still a work-in-progress.
In you’re above example, you’re using the watch task it looks like which will watch files and rebuild (which it did successfully) but there isn’t a server associated with that yet. We are working on a serve task right now.
Ultimately, developers will still use ionic serve and ionic run but the underlying implementation will be much simpler than it is today.
More than likely you’re doing something wrong in the custom config. We don’t recommend doing this at this time and the config is very specific to the Ionic build process. We implemented it for you. This is very similar to the Angular CLI or create-react-app. It’s best to stay on the happy path.
If you need hooks to pre/post bundle or build, that is a different story and something we will be adding support for hopefully next week.
To be fair, Ionic has had its own CLI for years before Angular added theirs (and, in fact, was an inspiration for the Angular CLI :D) so this is more of us just doing what we’ve always done.
We’ve had the opportunity to test our theory that by using existing generic tools instead of ones targeted at the unique development process Ionic apps have (mobile, native deployment, etc. etc.), the developer experience suffers.
We are going to continue to build tools targeted at Ionic apps, even if that means we have to build custom versions of things. As another plus, we are reducing e the number of external dependencies Ionic apps have, which should make the toolchain more stable over time.
And as for how people get into Ionic, it definitely varies, but we see a ton of people coming to Ionic and then learning Angular because we use it. That’s also inline with some of the marketing we’ve been doing recently to build awareness with the generic web development community that may or may not even be using Angular. This is also good because if Ionic was only just an Angular mobile framework, that wouldn’t be very strong ground to stand on for us.
@max Thanks for taking the time to explain the though process rather than “Welp, we’re not doing it - so there.” Although I feel like having more generic tools makes things more flexible & easier to switch between apps vs sites (especially when they’re popular tools), I do think the end goal is the same; a stable build process thats not constantly being upended.
Although Ionic might have come first, Ionic is built on Angular; not the other way around. It only makes sense to help consolidate things & work together since they underpinnings are so similar. Although I respect the fact that you guys had a good idea first it makes things harder for the end users to keep up with when there are multiple cli’s that do 80% of the same thing, and they each have an entirely different build process.
I guess my overall gripe in the NG community is that everyone wants to build their own thing because it would be “better” but no one is trying to really get everyone on the same sheet of music. Yes, the notes are different, but the bottom line is one is melody and the other is harmony. Right now the musicians aren’t even in the same auditorium.
. I’m happy to explain our rationale and help.