Webpack for development

[PanayotCankov]

There PRs in the CLI and the nativescript-dev-webpack:

• CLI: Separate native and JS prepare code nativescript-cli#3116
• Webpack: feat: enable plugin to run through {N} CLI hooks nativescript-dev-webpack#299
  The implementation splits the "prepare" step into "prepare js" and "prepare native" and allows release builds using the CLI and web pack like tns run ios --bundle --release.

We basically want to extend this and have it for development builds. We need fast incremental web pack builds.

Problems:

• Switching on/off snapshot may leave artefacts in platforms/..../app that should be cleaned
• These take a lot of time:
  • Webpack Bundle Analyzer saved stats file to ./report/stats.json
  • Webpack Bundle Analyzer saved report to ./report/report.html

TODO:

• Show messages in TS and SASS plugins when they skip due to --bundle option.
• Show messages in Webpack plugin when rejecting the --env.snapshot option with reasons. Moved to Show messages when rejecting the --env.snapshot option nativescript-dev-webpack#441
• Devise strategy how to handle --bundle option without webpack plugin installed. Currently, build hangs without message.

Resources:
https://github.com/angular/angular/tree/master/packages/compiler-cli
angular/angular#18818

[PanayotCankov]

time ./node_modules/.bin/ngc -p tsconfig.aot.json

With tns-platform-declarations:

NG codegen: 5881.254ms
NG downlevel: 690.687ms
TS I/O Read: 223ms
TS Parse: 10001ms
TS Program: 16555ms
TS I/O Write: 216ms
TS Bind: 8881ms
TS Check: 1164ms
TS transformTime: 590ms
TS printTime: 682ms
TS Emit: 1282ms

real	0m29.511s
user	0m30.300s
sys	0m1.217s

Without tns-platform-declarations:

NG codegen: 5840.692ms
NG downlevel: 762.195ms
TS I/O Read: 118ms
TS Parse: 1745ms
TS Program: 3781ms
TS I/O Write: 215ms
TS Bind: 1116ms
TS Check: 1222ms
TS transformTime: 574ms
TS printTime: 654ms
TS Emit: 1238ms

real	0m13.376s
user	0m14.343s
sys	0m0.775s

[MartoYankov]

DLL plugins:
https://robertknight.github.io/posts/webpack-dll-plugins/
https://webpack.js.org/plugins/dll-plugin/

Example for Angular with AOT and DLL and lots more:
https://github.com/qdouble/angular-webpack2-starter/blob/master/webpack.config.ts

[PanayotCankov]

It looks like compiling without the code generation (AoT) in web pack makes somewhere a web pack context that recursively includes all *.module.ts files generated by the angular compiler. However our loader tries to load using require here, we should probably check how to import the modules from the context for the "no-aot in web" story to work.

We can further use similar approach to import all "-page.xml" and "-page.css" files from app/ for vanilla NativeScript apps.

[sis0k0]

We'll target Angular 5 and the new AngularCompilerPlugin for webpack.

[sis0k0]

For incremental builds we can use https://github.com/webpack-contrib/cache-loader.

[PanayotCankov]

To use skipCodeGeneration: true, we will have to deal with module.id being a number instead of string in web packed modules. This seems to be solvable by using __filename (which web pack seems to replace with path relative to app) and then deal with the calculation of absolute path here

[MartoYankov]

{N} CLI command webpack hook for development concerns:

• CLI hook parameters - During development, we would like to control on/off webpack plugins - snapshot, uglify, analyzer, aot etc. This means we have to pass options to the tns run command that are actually for the plugin hook. Currently, it's handled with --env.snapshot out of the box, but it's too generic - could interact with other hooks. Discus how we approach this or whether we want this at all. --webpack.snapshot perhaps?
• Dev/Release webpack setup - Alternatively, we can have hardcoded setups for development/release. For example for --release we always have snapshot, uglify etc and without the --release option we always turn them off. The pro is that it will be simpler for users out of the box and we won't have hook specific options. The downside is that you can't debug problems with these webpack plugins without modifying the webpack.config.
• The CLI --bundle option - What if there is no bundling plugin installed? Should we warn users that nothing will happen? Should the CLI install nativescript-dev-webpack automatically? Should we allow users to install their own bundlers?
• Conflicts with other hooks - typescript, sass etc. hooks currently execute on the same run with the webpack hook. Currently, the TS and SASS plugins check if the --bundle option is passed to the run command and stop the execution of the hooks. This means that if the --bundle option is passed but there is no webpack plugin installed, the build will hang.

After consulting with @Mitko-Kerezov, here is what we agreed:

• Using CLI command options for hooks is better than dev/release webpack configs.
• Passing parameters for hooks with the generic --env.option is fine for now.
• We should devise a strategy how to handle the --bundle option when there is no webpack.

[PanayotCankov]

Ok, so for development we will be targeting Angular 5 with the AngularCompilerPlugin and there are some changes that should happen, here is a list of some issues and how we are about to address them:

1. This NSModuleFactoryLoader doesn't work, We merged a "System.import" in the tns-core-modules though, so SystemJsNgModuleLoader does work now, it should be properly tested and replace our implementation.
2. AngularCompilerPlugin now does a TypeScript build in web pack and fails to figure our .android.css, .ios.html etc. resources, we will extend it and use private API to implement the resource resolution, also wrap its FS. This may be unstable! May brake with a patch! However we already talked about this with the angular team and are confident that we will eventually agree on a stable solution using only public APIs in the near future.
3. The web pack config will change drastically but update scripts will be provided and the web pack config will probably look similar to this

[sis0k0]

I'm not sure if we should provide update scripts. I think we should document the changes in the webpack configuration and release v1.0, because:

1. The webpack configs will be changed a lot.
2. The workflow will be pretty different, too - using the {N} CLI instead of npm scripts.
3. We discussed that we can turn the snapshot plugin to a loader - that will also affect the webpack configuration. (maybe this can be done later)