Ok, i made it to work by changing run:before to run:after
"build:before": "build",
"run:before": "build",
"run:after": "watch"
But, really, am I the only one whose “watch” not getting triggered on livereload?
2 Likes
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.
Thanks,
Dan
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.
Thanks,
Dan
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.
Thanks,
Dan
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 think that’s a positive thing. The ecosystem wants to come up with new solutions to problems that might not be available in the stock toolkit. Remember ngrouter and uirouter?
The Angular CLI has been a long time coming and it’s not super stable yet. We decided early on that we didn’t want to rely on it being ready for what we needed, because then we risked waiting too long when we could have a solution right now. I feel validated in that given where the ng CLI is today.
That might change down the road, we keep an eye on it, but even then we’d probably use it under the hood like we do ngc.
Yep, I used the ionic-app-scripts webpack config just as I used the rollup config.
Anyway, I need Server Side Rendering and ionic-app-scripts doesn’t support it yet.
I appreciate that you have a desire to make things “just work” as best you can, but there are inevitably going to be last mile problems that there just isn’t any way you can solve in the general case. Without app developers having the ability to make at least some custom configuration, apps just can’t be built.
If you want concrete examples, until node-forge changes its packaging style, the recommended solution for using it with webpack involves declaring an alias and marking the module as noParse. In order to get node-uuid to work, I need to mark crypto as an external global.
1 Like
Are you using Universal? I’d love to chat more about that offline if so.
This is on our roadmap.
Thanks,
Dan
1 Like
Understood. In that case, I see no reason you couldn’t use the custom config but keep our stuff in place and add your stuff to it.
I totally agree with you that developers need hooks, etc. Customization is essential to do this right as there are a million business cases we can’t account for.
To get started, we’re targeting the 80% of users that want something simple, and we’ll figure out the remaining 20% that need customization in the coming weeks.
Thanks,
Dan
Yes. I`m trying with this starter > https://github.com/angular/universal-starter.
How can we chat about this?
1 Like
I would love to be able to do that, but the only documentation I have seen involves replacing the config file wholesale. If I try copying node_modules/@ionic/app-scripts/config/webpack.config.js to the main project folder and use it by adding -w ./webpack.config.js to the “ionic-app-scripts build” line, webpack apparently fails, but there is no reported error and main.js is not built. I assumed that this was caused by relative paths finding the ionic-loader, so I tried rewriting that part. However, the only way I could figure out how to get any feedback was to run webpack manually (instead of via ionic build). In that case, the interpolated {{}} variables aren’t set up, so I had to replace those with hardcoded values. What I ended up with:
var path = require('path');
module.exports = {
devtool: 'inline-source-map',
entry: "./src/app/main.dev.ts",
output: {
path: './www/build',
filename: 'main.js'
},
externals: {
"crypto": "crypto"
},
resolve: {
//modules: [path.resolve(__dirname, 'src'), 'node_modules'],
extensions: ['.js', '.ts', '.json'],
alias: {
'node-forge': 'node-forge/js/forge.bundle.js'
}
},
module: {
loaders: [
{
test: /\.ts$/,
loader: "ts"
},
{
test: /\.json$/,
loader: 'json'
}
],
noParse: [
'node-forge'
]
}
};
…and the following in tsconfig.json:
"exclude": [
"node_modules",
"src/app/main.prod.ts"
],
…and in package.json:
"scripts": {
"build": "ionic-app-scripts build --dev -w ./webpack.config.js",
Ugly, I realize, but ugly >>>>> nonfunctional.
Sourcemaps is not working;
Also, barrels isn’t working properly.
@symphony86 I’m having the same problem. Where did you change the setting?
Ok, i made it to work by changing run:before to run:after