feat(typescript-webpack-experimental): new experimental version of the webpack skeleton

This PR contains support of the Aurelia & Webpack duo, rewritten from scratch, solving over 20 Webpack-related issues, at the same time deprecating these dependencies:

aurelia-webpack-plugin v1
aurelia-bootstrapper-webpack

They're simply no longer needed.
New features:

integrates @MeirionHughes' template linter out of the box (decided against in the end, not prime-time ready)

uses jest with the aurelia-pal-nodejs and the new aurelia-loader-nodejs, instead of along with  karma, for blazing fast, modern and easy unit testing

integrates and gives an example for testing with aurelia-testing (see test/unit/welcome.spec.ts)

leverages jest's snapshot testing (in short: save rendered template HTML as text to a file, and then compare the rendered output with every run of the test; popular in the React circles), example also in the welcome.spec.ts

drops @easy-webpack configs in favor of a flat, yet still simple Webpack config file

Webpack now understands the dynamic nature of dependencies in Aurelia, thus the dependency graph is now very accurate. Aside from the old way of defining dependencies for Webpack, aurelia.build.resources in package.json which can still be used to define bundles, declaring dynamic dependencies is now much simpler, can can be achieved by simply placing a comment directly before the module ID literal. For example: DEPRECATED, see https://github.com/aurelia/pal/issues/17 for updated example
outdated example
aurelia.setRoot(/* @import */ 'app');

There are two modifiers that you can add to the comment, @lazy and @chunk('some-name'):
configureRouter(config: RouterConfiguration, router: Router) {
  config.title = 'Aurelia';
  config.map([
    {
      route: ['', 'welcome'],
      moduleId: /* @import */ './welcome',
      name: 'welcome', nav: true, title: 'Welcome'
    },
    {
      route: 'users',
      moduleId: /* @import @lazy @chunk('some-chunk') */ './users',
      name: 'users', nav: true, title: 'Github Users'
    },
  ]);

  this.router = router;
}

This is all you need to make a separate, lazily loaded bundle which contains a given route and all of its dependencies. No other configuration needed.

simple glob patterns (single * and double **) are now supported for adding/matching dependencies in build resources and importing from code
(e.g. /* @import('./path/*\/.js') */)

related .html and .css files of the same name as the ViewModel are now included as its dependencies by convention, you may configure additional extensions or other conventions by passing a method in the Webpack configuration file

hot reload for CSS imported in JS files works

beta version of hot reloading both Views and ViewModels

I'm marking this "experimental", since everything about this is a "breaking change" and it needs further testing by other people to iron out possible bugs. I've tried best I can to test this thoroughly, but it's still pretty fresh. Also, there are no docs written yet, especially for the webpack-dependency-suite, a collection of plugins and loaders which I've written with Aurelia in mind (but they're generic, hence deprecation of aurelia-webpack-plugin).
All this work was also prep for two more features that will now be possible:

integrated server side rendering
hot-reload for View templates, and later, ViewModels

Comments are welcome.
This skeleton won't work until the dependent PR's are merged and published to NPM as new versions.
@EisenbergEffect This PR is blocked by:

[x] Creating a repo under @aurelia, moving and publishing: aurelia-loader-nodejs
[x] Merging and publishing: https://github.com/aurelia/loader-webpack/pull/25
[x] Merging and publishing: https://github.com/aurelia/templating/pull/491
[x] Publishing: https://github.com/aurelia/pal-nodejs (already merged https://github.com/aurelia/pal-nodejs/pull/16)
[x] Publishing: https://github.com/aurelia/protractor-plugin (small fix)
[x] Merging: https://github.com/aurelia/bootstrapper/pull/50
[x] Merging: https://github.com/aurelia/pal-nodejs/pull/20
[x] Merging: https://github.com/aurelia/pal/pull/16
[x] Merging: https://github.com/aurelia/pal-browser/pull/14
[x] Merging: https://github.com/aurelia/pal-worker/pull/4
[x] Merging: https://github.com/aurelia/bootstrapper/pull/52
[x] Publishing: pal
[x] Publishing: pal-nodejs (again, new globalize fixes)
[x] Publishing: pal-browser
[x] Publishing: pal-worker
[x] Publishing: bootstrapper
[x] Publishing: hot-module-reload
[x] Publishing: loader-webpack
[x] Review proposal: https://github.com/aurelia/pal/issues/17
[x] Merge and publish: https://github.com/aurelia/pal/pull/20
[x] Write a Webpack plugin to support https://github.com/aurelia/pal/issues/17
[x] Publish the new Webpack plugin
[x] Update this PR to use the above mentioned plugin
[x] Replace bnr and concurrently dependencies

@EisenbergEffect This PR is blocked by:

Creating a repo under @aurelia, moving and publishing: aurelia-loader-nodejs
Merging and publishing: https://github.com/aurelia/bootstrapper/pull/50
Merging and publishing: https://github.com/aurelia/loader-webpack/pull/25
Merging and publishing: https://github.com/aurelia/templating/pull/491

Fixes:

https://github.com/aurelia/loader-webpack/issues/21
https://github.com/aurelia/loader-webpack/issues/20
https://github.com/aurelia/loader-webpack/issues/19
https://github.com/aurelia/loader-webpack/issues/24
https://github.com/aurelia/webpack-plugin/issues/44
https://github.com/aurelia/webpack-plugin/issues/51
https://github.com/aurelia/webpack-plugin/issues/53
https://github.com/aurelia/webpack-plugin/issues/54
https://github.com/aurelia/webpack-plugin/issues/64
https://github.com/aurelia/webpack-plugin/issues/65
https://github.com/aurelia/webpack-plugin/issues/67
https://github.com/aurelia/webpack-plugin/issues/71
https://github.com/aurelia/webpack-plugin/issues/72
https://github.com/aurelia/webpack-plugin/issues/74
https://github.com/aurelia/webpack-plugin/issues/76
https://github.com/aurelia/webpack-plugin/issues/78
https://github.com/aurelia/webpack-plugin/issues/80
https://github.com/aurelia/skeleton-navigation/issues/628
https://github.com/aurelia/skeleton-navigation/issues/667
https://github.com/aurelia/binding/issues/376
https://github.com/aurelia/testing/issues/21
https://github.com/aurelia/skeleton-navigation/issues/688
https://github.com/aurelia/skeleton-navigation/issues/666
https://github.com/aurelia/skeleton-navigation/issues/649

Wow @niieani this is fantastic. Seriously, great work. Excited for server-side rendering and hot module replacement additions.

@niieani really great work. Webpack config is easy to read and understand. Can't wait for the hot module replacement. Thanks!

@niieani Great work. Thank you for the great efforts. Now anticipating the server-side rendering.
Anything experimental also for ESnext?

Am I the only who looks at the skeleton files (specially package.json) and thinks there too many technologies used here --> too many things to learn in advance --> too much to comprehend --> too much for a skeleton project!
I really acknoweldge the efforts and optimizations done here by @niieani, but unless this is simplified or a walk-through documentation is provided (that shows how package.json and webpack.config.ts gradually grow), then this skeleton will be very intimidating and turn off for newcomers.

@niieani Should @easy-webpack/core still be a dependency in packages.json?

@mttmccb @easy-webpack/core provides the merging function, used to generate the final config from declared objects. It's much easier to turn features on/off that way.
@nashwaan I've tried to reduce the number of technologies used here, compared to the old skeleton. However the number of dependencies is still large because of all the basic loaders and Webpack plugins, and then the testing environments (although jest requires much fever than karma).
This is the bare minimum for a modern SPA project with unit and e2e testing. Have a look at the React boilerplate or Angular2 skeletons. They have a similar, if not larger number of dependencies.
Config file is simplified and easy to remove features, although there are barely any to remove - it's set up for a simple build system for both development and production builds, and that's all.

From Gitter:

stevies @stevies 12:31
@niieani - do you have plans for the non-typescript skeleton?

@stevies converting the TS skeleton to use babel should be very easy, I didn't do it yet just because it would be too much maintaining for an "experimental" skeleton. After we get feedback and iron out any remaining bugs we can get a JS skeleton running.

Thanks so much @niieani  for this monumental achievement in aurelia+webpack world. Please when can we start using this?
Please I will welcome your assistance. I just moved my project folder to my machine running LinuxMint. I did npm install and then npm start.
I got this error
Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration has an unknown property 'metadata'. These properties are valid:
   object { amd?, bail?, cache?, context?, dependencies?, devServer?, devtool?, entry, externals?, loader?, module?, name?, node?, output?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, stats?, target?, watch?, watchOptions? }
   For typos: please correct them.
   For loader options: webpack 2 no longer allows custom properties in configuration.
     Loaders should be updated to allow passing options via loader options in module.rules.
     Until loaders are updated one can use the LoaderOptionsPlugin to pass these options to the loader:
     plugins: [
       new webpack.LoaderOptionsPlugin({
         // test: /\.xxx$/, // may apply this only for some modules
         options: {
           metadata: ...
         }
       })
     ]

I am using one of the webpack solution you made sometimes ago as replacement for @easywebpack.
Please what is the possible solution to this mess?

@smithaitufe I think the reason is that your project had unlocked SemVer for the Webpack dependencies, and since there were some breaking changes in the recent webpack betas, a new npm install had caused breaking modules to get installed. Either clone a fresh skeleton and move your project files over (src folder) + install your dependencies, or ensure you have the correct dependencies based on the fresh skeleton.
If you want to further reply to this matter, please open a separate issue or ask on Gitter, this PR is about something else.

@EisenbergEffect Any idea when this will be completely merged and transformed over to ESnext? My project is currently rocking a hefty 22mb 0.chunk.js file and I would really love to use the new code splitting feature asap.  I'd be happy to test it out for you guys as soon as I had an ESnext version I could plug into my project.

Within a week I hope. Things could come up in testing. We need to review and fix up a few more things first too.

@niieani Hi, I tried your experimental skeleton and on Windows 10 after lunch npm start, I'm getting this errror:
><EMAIL_ADDRESS>start G:\skeleton-typescript-webpack-experimental
> bnr webpack:dashboard

running better-npm-run in G:\skeleton-typescript-webpack-experimental
Executing script: webpack:dashboard

to be executed: "$LOCAL/webpack-dashboard -- $LOCAL/webpack-dev-server --hot --inline --open"
'$LOCAL' is not recognized as an internal or external command,
operable program or batch file.

@lares83 the repo is not ready to be tested yet, it's waiting on some PRs to get merged. Also, it's probably not Windows ready yet.

I just wanted to report back that I was able to get this running on my mac without errors.  I do look forward to an official release though that I can migrate over.

@jasonbiondo there's an example for how to do code chunking in the first post of this PR. To reiterate, add a special comment directly before the module name you are requiring, e.g. like this:
/* @import @lazy @chunk('some-chunk') */ './my-module'

@import signifies the module should be added as a dependency to the file
@lazy (optional) signifies the module (and its dependencies) should be separated into a different chunk and loaded asynchronously
@chunk('some-name') (optional) signifies the module (and its dependencies) should be separated into into a different chunk with the name 'some-name'

You may combine @lazy with @chunk to get an asynchronous named-chunk.

@niieani  Thanks for the update.  I edited the app.ts file and ran a build but I'm not seeing the chunk file being created.
This is the change I made:
config.map([       { route: ['', 'welcome'], name: 'welcome',      moduleId: './welcome',      nav: true, title: 'Welcome' },       { route: 'users',         name: 'users',        moduleId: /* @import @lazy @chunk('some-chunk') */ './users',        nav: true, title: 'Github Users' },       { route: 'child-router',  name: 'child-router', moduleId: './child-router', nav: true, title: 'Child Router' }     ]);
Was that correct? Shouldn't the some-chunk file be created?

@jasonbiondo your change is correct. Not sure why it wouldn't work since it works on my end. You could instead try defining the chunk in aurelia.build.resources of package.json:
"resources": [{ "path": "users", "lazy": true, "chunk": "some-chunk" }]

Let me know if that works.
I'd wait until we merge the remaining PRs and we can all do a bit of proper testing of the new stack. I might make the ./users path chunked and async by default (in the skeleton) and add one integration test that verifies that an extra chunk was indeed created and loads on router click.

@niieani I'm getting a warning in terminal with adding that in as well. Also the file is still not created upon completion. Here is full trace:
`
Jasons-MacBook-Pro-2:skeleton-typescript-webpack jasonbiondo$ npm run build

<EMAIL_ADDRESS>build /Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
npm run build:dev

<EMAIL_ADDRESS>prebuild:dev /Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
npm run clean:dist

<EMAIL_ADDRESS>clean:dist /Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
del-cli dist

<EMAIL_ADDRESS>build:dev /Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
cross-env NODE_ENV=development npm run webpack -- --progress --profile

<EMAIL_ADDRESS>webpack /Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
cross-env TS_NODE_PROJECT=tsconfig.tsnode.json TS_NODE_FAST=true ./node_modules/.bin/webpack "--progress" "--profile"

3901ms building modules
1ms sealing
0ms optimizing
0ms basic module optimization
1ms module optimization
2ms advanced module optimization
4ms basic chunk optimization
0ms chunk optimization
3ms advanced chunk optimization
0ms module and chunk tree optimization
5ms module reviving
1ms module order optimization
1ms module id optimization
0ms chunk reviving
1ms chunk order optimization
1ms chunk id optimization
5ms hashing
0ms module assets processing
15ms chunk assets processing
1ms additional chunk assets processing
1ms recording
0ms additional asset processing
50ms chunk asset optimization
1509ms asset optimization
29ms emitting
Hash: 52baf11ed06a912954ed
Version: webpack 2.1.0-beta.27
Time: 8002ms
Asset       Size  Chunks             Chunk Names
fa2772327f55d8198301fdb8bcfc8158.woff    23.4 kB          [emitted]
674f50d287a8c48dc19ba404d20fe713.eot     166 kB          [emitted]
b06871f281fee6b241d60582ae9369b9.ttf     166 kB          [emitted]
fee66e712a8a08eef5805a46892932ad.woff      98 kB          [emitted]
af7ae505a9eed503f8b8e6982036873e.woff2    77.2 kB          [emitted]
f4769f9bdb7466be65088239c12046d1.eot    20.1 kB          [emitted]
89889688147bd7575d6327160d64e760.svg     109 kB          [emitted]
e18bbf611f2a2e43afc071aa2f4e1512.ttf    45.4 kB          [emitted]
912ec66d7572ff821749319396470bde.svg     444 kB          [emitted]
448c34a56d699c29117adc64c43affeb.woff2      18 kB          [emitted]
app.bundle.js    1.05 MB       0  [emitted]  app
aurelia.bundle.js    1.47 MB       1  [emitted]  aurelia
aurelia-bootstrap.bundle.js     677 kB       2  [emitted]  aurelia-bootstrap
styles.css     199 kB       0  [emitted]  app
favicon.ico    2.25 kB          [emitted]
index.html  802 bytes          [emitted]
[48] ./src ^./.*$ 2.56 kB {0} [built]
[] -> factory:204ms building:37ms dependencies:590ms = 831ms
[49] multi app 28 bytes {0} [built]
factory:0ms building:1ms = 1ms
[50] multi aurelia 244 bytes {1} [built]
factory:0ms building:0ms = 0ms
[51] multi aurelia-bootstrap 76 bytes {2} [built]
factory:0ms building:0ms = 0ms
+ 92 hidden modules
WARNING in ./src ^./.$
Module not found: Error: Can't resolve 'bundle' in '/Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack/src'
BREAKING CHANGE: It's no longer allowed to omit the '-loader' prefix when using loaders.
You need to specify 'bundle-loader' instead of 'bundle'.
@ ./src ^./.$
@ ./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js
@ multi aurelia
WARNING in ./src ^./.$
Module not found: Error: Can't resolve 'bundle' in '/Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack/src'
BREAKING CHANGE: It's no longer allowed to omit the '-loader' prefix when using loaders.
You need to specify 'bundle-loader' instead of 'bundle'.
@ ./src ^./.$
@ ./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js
@ multi aurelia
Child html-webpack-plugin for "index.html":
+ 4 hidden modules
Child extract-text-webpack-plugin:
+ 2 hidden modules
Child extract-text-webpack-plugin:
Asset     Size  Chunks             Chunk Names
674f50d287a8c48dc19ba404d20fe713.eot   166 kB          [emitted]
912ec66d7572ff821749319396470bde.svg   444 kB          [emitted]
b06871f281fee6b241d60582ae9369b9.ttf   166 kB          [emitted]
fee66e712a8a08eef5805a46892932ad.woff    98 kB          [emitted]
af7ae505a9eed503f8b8e6982036873e.woff2  77.2 kB          [emitted]
+ 8 hidden modules
Child extract-text-webpack-plugin:
Asset     Size  Chunks             Chunk Names
f4769f9bdb7466be65088239c12046d1.eot  20.1 kB          [emitted]
89889688147bd7575d6327160d64e760.svg   109 kB          [emitted]
e18bbf611f2a2e43afc071aa2f4e1512.ttf  45.4 kB          [emitted]
fa2772327f55d8198301fdb8bcfc8158.woff  23.4 kB          [emitted]
448c34a56d699c29117adc64c43affeb.woff2    18 kB          [emitted]
+ 7 hidden modules
Jasons-MacBook-Pro-2:skeleton-typescript-webpack jasonbiondo$
`
Here is the change on my end:
"aurelia": {     "build": {       "resources": [{ "path": "users", "lazy": true, "chunk": "some-chunk" }]     }   },

@jasonbiondo yep, the problem is that you're not using the latest version of the loader-webpack, because that wasn't released yet.

@niieani I see.  I cloned the loader-webpack, changed the name to aurelia-loader-webpack and moved it to my node modules dir but I'm still getting the error.

@jasonbiondo because the loader is not built. You don't need to clone manually, npm supports git natively. There's a separate test branch that has the loader built. Just do:
npm install github:aurelia/loader-webpack#experimental-release --save-dev

@niieani any idea why this is invalid?
Jasons-MacBook-Pro-2:skeleton-typescript-webpack jasonbiondo$ npm install github:aurelia/loader-webpack#experimental-release --save-dev
<EMAIL_ADDRESS>/Users/jasonbiondo/Sites/skeleton-navigation/skeleton-typescript-webpack
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>invalid (git://github.com/aurelia/loader-webpack.git#dea401995e605c44fa39df8934ad970e91044d71)

Looks like you have loader-webpack twice, once the 2.0.0 version, once from the bootstrapper-webpack, which again, wasn't yet released (actually we're switching to a universal boostrapper).
I think it will be easiest if you simply wait a few more days for the related packages to be released and then try the skeleton again.

@niieani, fantastic work!
However as a TypeScript user (fan of strong typing, type safety, etc) I'm not that fond of the hints in comments, that could easily contain typos that are not detected by the compiler:
moduleId: /* @inport @Iazy @junk('some-chunk') */ './users',
So i have an idea for improvement: I'd propose using special functions that takes the module id and simply returns it at runtime, but for aurelia webpack support we'd be able to pass in additional arguments (modifiers/hints), that would be read by build system at build-time, and that would be ignored at runtime. Also this function could be documented, so whoever looks at its documentation (for example in TypeScript declaration file) would understand what it is used for without having to wonder what is encoded into the comments and who might use/need them.
For example, I came up with few alternative syntaxes that I might prefer over using comments:
1)
import {wp} from 'hypothetical-aurelia-webpack-extension';
...
wp.moduleId('./users', {
  import: true,
  lazy: true,
  chunk: 'some-chunk'
}),
...

or perhaps even smth like:

import {wp, IMPORT, LAZY} from 'hypothetical-aurelia-webpack-extension';
...
wp.moduleId('./users', IMPORT | LAZY, 'some-chunk'),
...

or if  @chunk('some-chunk') should only be used when @lazy is used
AND
if  @lazy should only be used when @import is used, then the syntax could be simplified even more:
then:
a) instead of
/* @import @lazy @chunk('some-chunk') */ './users'
following:
wp.moduleId('./users', true, 'some-chunk')
b) instead of
/* @import @lazy */ './users',
following:
wp.moduleId('./users', true)
c) instead of
/* @import */ './users',
following:
wp.moduleId('./users')

@niieani, what do You think?

@atsu85 I have thought about this for a while, and while comments are not the best, they're in some ways better than special functions (which I've also thought about).
The problem is, when you use especial functions your code is not portable anymore. I was hoping that with the new skeleton, you can run the same code, without any changes (aside from configuration), with Aurelia CLI, RequireJS, SystemJS, JSPM, etc.
Once we start adding functions which are loader-specific, we loose portability. There's indeed an alternative, we could create a simple function which returns the same string, i.e. in the simplest form:
function dynamicImport(moduleId) {
  return moduleId;
}

Then the parser would look for dynamicImport('some-module') use that and even replace the function with the string directly in the output code.
This is the other relatively good solution I could get behind of, since it wouldn't break other-module compatibility. But when switching / using other loaders, you'd end up with an unnecessary call to a function in the output build. Maybe that's not such a big problem. I'll need to think about it some more.

@niieani what is that universal bootstrapper you mentioned about ?

@bigopon it will be aurelia-bootstrapper v2.0.

I am trying to get the skeleton-navigation for esnext-webpack to support es2015 spread syntax.
I had to install the following modules
npm install --save-dev babel-preset-es2015 babel-preset-es2015-loose babel-preset-es2015-loose-native-modules babel-preset-stage-1
Note: I am not good at webpack.
After installation, I edited the webpack section of my .babelrc to something like this
 "webpack": {
      "plugins": [
        "transform-decorators-legacy",
        "transform-class-properties"
      ],
      "presets": [
        [
          "es2015",
          "stage-1"
        ],
        [
          "env",
          {
            "targets": {
              "browsers": [
                "last 2 versions",
                "not ie <= 11"
              ]
            },
            "loose": true,
            "modules": false
          }
        ]
      ]
    },

Yet, it won't work. Please what do I need to do?

@smithaitufe you do not want: babel-preset-es2015-loose babel-preset-es2015-loose-native-modules these packages were deprecated! Also, how is this related to this PR? Maybe you want to start a different issue...

@niieani no pressure but it's been a few more days :) @EisenbergEffect What is still pending before this goes out?

@niieani
I am sorry for repeating this mistake. I should have checked properly. Thanks for the tip. So, I will simply uninstall those. I guess it will still work.

@jasonbiondo see the end of the first post for the TODO list of remaining PRs.

@niieani said:

while comments are not the best, they're in some ways better than special functions (which I've also thought about).

I'd say that it depends on the type of the function - it wouldn't be better, if the function implementation would be Webpack specific, but that is not what i suggested.
And I agree that

Once we start adding functions which are loader-specific, we loose portability.

but I wasn't talking about function, that has Webpack loader specific implementation. With this:

I'd propose using special functions that takes the module id and simply returns it at runtime, but for aurelia webpack support we'd be able to pass in additional arguments (modifiers/hints), that would be read by build system at build-time, and that would be ignored at runtime.

I wasn't talking about loader-specific functions, as a matter of fact, with my last example (3.c) I was describing exactly what You wrote (I just used different name for the function and i imported the function within wp namespace, so I had pretty-much the same in mind what You described with Your sample:
function dynamicImport(moduleId) {
  return moduleId;
}

but i also thought that this function (if it was described with TypeScript) would have additional parameters that are ignored at runtime, so here is what I had in mind for third example:
/**
 * This function only returns its first argument. Implementation of this method has no
 * side-effects at runtime, but at build time module bundlers, such as Aurelia Webpack bundler
 * could inspects application source code and when seeing invocation of this function, they
 * could parse the arguments for bundling the module (see the optional arguments bellow).
 * @param moduleId - module id
 * @param lazy - (optional) signifies the module (and its dependencies) should be separated into a different chunk and loaded asynchronously
 * @param chunkName - (optional) signifies the module (and its dependencies) should be separated into into a different chunk with the name 'some-name'
 * @return moduleId that was passed in as a first argument
 */
function dynamicImport(moduleId: string, lazy = true, chunkName?: string ): string {
  return moduleId; // just return the first argument, ignore everything else
}

So Your concerns regarding compatibility with portability and other module loaders would not be a problem at all (as the function implementation wouldn't be coupled with Webpack):

when you use special functions your code is not portable anymore. I was hoping that with the new skeleton, you can run the same code, without any changes (aside from configuration), with Aurelia CLI, RequireJS, SystemJS, JSPM, etc.

So when not using Webpack bundler(or any other bundler, that could take advantage of this metadata), the function could be left there or be replaced with its first argument just like the comments could be left there or be removed when not using Webpack - I don't see a disadvantage here either. At least when Webpack is not used, then the developer can see what the purpose of the function was and be confident that if he replaces function with its first argument, the app would work the same way.
So the only really-really small downside would be a tiny runtime penalty for additional function call, that could be eliminated at build-time for all module loaders, including Webpack itself (after it has parsed the method parameters for bundling):

Then the parser would look for dynamicImport('some-module'), use that and even replace the function with the string directly in the output code.

But to be honest, I don't think that the rewriting method call to string constant would actually be worth the effort - I wouldn't miss it, but maybe someone would ;)
Anyway, @niieani, please consider again using the non-webpack-specific function instead of comments.

@atsu85 yes, I'm strongly inclined to write a second loader which will not use comments but an importable method, similar to your proposal.
I think rewriting method call to string constant is definitely worth the effort, I think it should be very simple to do with Webpack, too. The only thing I'm worried about is the small performance penalty for non-webpack scenarios, unless we'd, say, make a gulp version of that method-to-string-constant trimmer so it works universally.

@niieani

I'm strongly inclined to write a second loader which will not use comments but an importable method, similar to your proposal.

nice 👍. Just one question: You mentioned second loader - I'm not very familiar with Webpack, but... As I understand Webpack is not just a module loader (like RequireJS, SystemJS, ...), but it also contains a module bundler (that does its job at build time), in addition to module loader (that serves modules/bundles at runtime when browser loads new components).
So with that understanding (that might be totally wrong as I expected that bundling for production and development are very similar) I'd expect that parsing the metadata (modifiers/hints from comments, like /* @import @lazy @chunk('some-chunk') */) is done in a bundler, right? And i also thought that the part of the code that parses the metadata is quite isolated from rest of the module bundler (not to mention the module loader), so it should be fairly simple to replace the implementation that works with comments, or am i totally wrong?

@atsu85 I think we misunderstood each other, as there are no client-side loaders in Webpack. Webpack is about transforming code and bundling.
Webpack Loaders are simply code transformations that can also do things like add dependencies to the dependency graph. Currently there's the comment-require-loader that I wrote, which simply appends the dependencies based on the comments after parsing them.
I wrote about "writing a second loader", because we'd need another one which would do something very similar:

parse the code
find the necessary methods
extract the useful information from the passed in parameters
append the extracted dependencies
modify the AST to replace method calls with pure string literals
update the SourceMap

The comment loader works almost the same as above, but it doesn't need to update the SourceMap.

@niieani @EisenbergEffect Any update on this being released?

Heads up @niieani typescript 2.0 -> 2.1 is breaking for me. latest linter locks to 2.0.x

@jasonbiondo Rob started releasing some of the dependencies. I'll try to update this PR ASAP.
@MeirionHughes do you mean peer-dependency conflicts?

No, no just within the Linter; so if you get issue with trying to upgrade to typescript 2.1 here, and the Linter is to blame you'll know why.

@niieani All dependencies published :)

@EisenbergEffect amazing, thanks!
I'll try to get back to this and update the dependencies here soon.

@niieani Any idea when this will be merged now that the deps are done?

@jasonbiondo I'm planning to do it this weekend.

@jasonbiondo I can feel your excitement lol.

@niieani I am curious how webpack 2 impacts this ?

@forestmarie I've been waiting for this release since September :)

@jasonbiondo I understand - that open source life requires a lot of patience.

Just to update everyone waiting, I've got this PR updated and running locally using the newly published dependencies and the shiny HMR plugin nicely. However I wanted to wait until we get https://github.com/aurelia/pal/issues/20 merged and published so that I can swap out the temporary comment-loader implementation with a plugin (which is almost ready) based on this proposal: https://github.com/aurelia/pal/issues/17.
The reason is: I don't want people migrating between different syntaxes again and again. Replacing the comment-loader should also improve the compilation speed (cause the code won't need to be parsed twice), and should be more robust overall (see @atsu85's objections in the above discussion).
So it's going to be a couple more days.
I'll try and push the updates to this PR tomorrow anyway, for those that would like to play with the new setup, but please expect the comments loader to be swapped out before this gets merged.

OK, I've pushed some stuff to that branch. Still incomplete, and needs some cleanup, but should work (no promises though).

@niieani are these commits the final ones before merge? I'm getting these errors on npm install:
npm ERR! Darwin 15.6.0
npm ERR! argv<EMAIL_ADDRESS>"/usr/local/bin/npm" "install"
npm ERR! node v4.7.0
npm ERR! npm  v2.15.9
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package<EMAIL_ADDRESS>does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants webpack@1 || ^2.1.0-beta
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants<EMAIL_ADDRESS>npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants webpack@*

In the meanwhile, I'm in the process of adding the @import comments in all dependencies of my modular app. Do I need to add the comment also in plugins configure function, where I register resources with configuration.globalResources( [ './res1', './res2' ])?

@heruan Yes.
configuration.globalResources([
  /* @import */ './res1',
  /* @import */ './res2'
])

Also you need to using plugin() method with @import for feature in main.js.
aurelia.use.feature('resources');

to
aurelia.use.plugin(/* @import */ 'resources');

Thank you @hongikeam for the clarification. What about custom attributes which refers to view-models? For example <compose view-model="./my-vm"> or any other user-defined attribute referring to view-models?

webpack-dependency-suite's comment-loader affects only js or ts.
But I wonder view-models will working with webpack-dependency-suite.
@heruan I'm just tested. view-models are working perfectly. You should just write <compose view-model="./my-vm">

@heruan don't spend time on adding /* @import */ comments. This idea is going to be dropped in favour of a different API.
The current thinking is to use a special well-known function instead, most likely
PLATFORM.moduleName('./my-vm').

Thank you @jods4 the news is very appreciated since the comment-thing reminded me awful past experiences resulting in unmaintainable code! I'll stay in touch with that issue and I hope to have the new skeleton released soon. @niieani any ETA?

@heruan You can ignore peerinvalid problems for now.
@jods4 is correct, don't get attached to the /* @import */ syntax, as we'll be getting rid of that (well, the plugin will still exist, but won't be in the skeleton by default, but if somebody wants to use it, we can't stop them :D), it'll be discouraged.

Thank you @niieani, for now I reverted back to the webpack-plugin and bootstrapper-webpack. Any ETA for this PR to get merged and released?

@niieani Do you think this solution will be all hammered out within the next month?  I rather wait personally for it to mature.  Let me know.

@heruan @forestmarie not sure about the ETA for when this will be fully stable. We'll need to get lots of feedback from people who try this out, so after this is updated with the new API (I'll try to do that this week) and is cleaned up a bit more, we'll officially announce it and get more people testing it with their small and medium-sized solutions.
It's hard to answer the question, as I don't know what problems might still be discovered. Assuming only minor problems, January should be good enough.
Before we make this stable, we'll also need to write some documentation for it, so if anybody who understands what's changed would like to help out with Doc PRs for the new Webpack stack, we'd be really happy to merge!

@niieani We have an es-next app that is in production. I am trying to gauge what this PR means for us (i.e. will this be integrated into the skeleton soon and if so, is it a good idea to try and migrate a production app to it or should we wait?

@istrau3 Well, the old webpack-skeleton approach works, and is used in production by tens, if not hundreds, of users, but has some annoying bugs. The new approach solves most of those bugs and annoyances and adds some useful features, but might also introduce new bugs -- we don't know, because the new approach wasn't tested enough yet.
We plan to integrate this to skeleton repo before the end of the month. But it should ultimately be up to you to do the cost-benefit for your particular application, and decide what is the right course here.
If you start using the new PLATFORM.moduleName API, but still with the old stack (aurelia-webpack-plugin), upgrading to the new stack will only be a matter of swapping out the Webpack configuration file and some dependencies. So if you don't need any of the new features added by this PR, it might be easier to use the old stack in a forward-compatibile way, and then switch to the new one after it's been field-tested.
Hope that helps.

@niieani you may want to have a look at https://github.com/jods4/aurelia-webpack-build/tree/master/demos/01-No splits
It is a very small, very simple Aurelia application with a quite simple webpack build that works.
The approach here is a no-split, all-in-one option that is suitable for small to medium sized projects.
It works using this webpack plugin that I wrote, which can include arbitrary globs as dependencies to any entry point. In the example above, I use it to pull my entire src folder in the build.
https://github.com/jods4/aurelia-webpack-build/blob/master/demos/01-No splits/GlobDependenciesPlugin.js
Of course, large application with splits would need a way to analyze dependencies precisely and introduce split points (that would be PLATFORM.moduleName().
What I don't like in this setup:

the list-based-require-loader that is a bit verbose, but which we'll soon replace by some kind of new AureliaDependencyPlugin().
the plugin that creates module id, which seems too complicated to configure but I haven't had time to look at it yet.

I also tested HMR for LESS and it works. Don't know how to try HMR for Aurelia yet.

I managed to get around the issues with the Better Npm Scripts not running because of .env files not working in Windows and can get my code built, but I am seeing this issue: aurelia-hot-module-reload.js:46 Uncaught SyntaxError: Unexpected identifier
This points to an async function: async handleModuleChange(moduleId, hot) {
I experienced this with the skeleton as of this current PR.

@Vheissu fixed the async refs (it was using es2017 builds where existent; i had it in there for better debugging experience using Chrome, which supports await/async).

I cannot get this to work. It gives an error that aurelia-pal-browser could not be loaded.
Some investigation:
aurelia-bootstrapper.preparePlatform calls aurelia-bootstrapper.initializePal
aurelia-bootstrapper.initializePal calls WebpackLoader.loadModule('aurelia-pal-browser')
WebPackLoader.loadModule calls WebpackLoader.import('aurelia-pal-browser', true)
WebpackLoader calls __webpack_require__ which does not find aurelia-pal-browser
Do I miss something?

@arjendeblok I am getting the same. Trying to look into it to see if I can figure out what's going on.

I threw the following into main:
import 'aurelia-pal-browser';

Now I am getting the following error:
Uncaught (in promise) TypeError: palModule.initialize is not a function
    at aurelia-bootstrapper.js:95

@niieani I now have another basic setup that traces JS dependencies rather than globbing everything. It includes designated strings in JS and well-known attributes in HTML.
https://github.com/jods4/aurelia-webpack-build/tree/master/demos/02-Traced_deps/webpack
In JS strings are designated by PLATFORM.moduleName, the webpack plugin that performs that is here:
https://github.com/jods4/aurelia-webpack-build/blob/master/demos/02-Traced_deps/webpack/AureliaDependenciesPlugin.js
It is configurable so people are free to use shorter names if they prefer.
In HTML, there are a few hard-coded attributes (require[from], [view], [view-model]) that are caught by the combination of a loader html-requires-loader and HtmlDependenciesPlugin.
I think the implementation is slightly better than yours as the loader is a very small and simple passthrough that doesn't modify the file contents. This means it should be chained into html-loader, which can be used for everything that you might want to use it for (e.g. handle image dependencies).
None of those support globbing/patterns at the moment, only constants.
In the demo linked above, HTML files themselves are still pulled in by globbing everything in src. The next step for me will be to link them by convention (.ts + .html pairs) or with PLATFORM.moduleName (e.g. @useView).

@Vheissu maybe it has something to do with the CommonsChunkPlugin part in the webpack.config.ts.
It references a vendor common part which could contain the Aurelia parts. I have seen this construct before but I cannot find a corresponding webpack.vendor.config.

Is there any chance you could fix some of the "annoying bugs" in the existing codebase - rather than just defer doing so to a completely new and as yet unfinished solution?  As it stands, using webpack with Aurelia is not really an option for a new project.

@stevies I have to disagree, we are using webpack/aurelia in a big enterprise application and it works. I even started a new fresh project with it. Yes there are bugs/hiccups, but thats the whole point of this Branch here to fix it. Of course it is not finished, the people are working in their free time. So any help is appreciated. For a starter, what problems do you have? Please create tickets and/or look at the list above to check if they are already fixed with this ticket here.

@stevies the problem of the old approach is there's no easy way to fix many of the bugs present. It would be "patching the patch". That's why I've rethought the whole concept and designed this new approach.
@jods4 I'll take a look when I have some free time. Sounds interesting.

Thanks for the explanation.  I been seriously caught out by the problem of not being able to run unit tests when using webpack.  I've had to live with that in my current project, but I can't do that again.  The Aurelia CLI has other issues for me so I don't really want to use that either.
I'm guessing that it will be a few more months before the new webpack approach is stable, and available for esNext.  I'll check back in then.

@stevies If the biggest problem for you is lack of support for aurelia-testing you could cherry pick the unit testing support from this branch, since it uses Node, completely avoiding Webpack (i.e. it will work with any configuration). Beware there might be edge cases which fail in the new NodeJS but do work under the Browser. Protractor tests still (obviously) use the browser and thus Webpack, but those are unrelated to the underlying changes.

@niieani just some quick feedback... I have been testing this out for about 3 hours and attempted to integrate my project but was unable to complete the migration.  I just simple can't seem to figure out why my less-loader doesn't work.  Overall, the webpack config is daunting with it being around 400 lines.  I'm not sure if this is going to be the version you plan on releasing but even for me, a developer with a fair amount of experience struggles to figure out how things are architected.
When I compare this webpack config to that of the stable release there is a huge difference in easy of use.  I'm sure it does all these awesome things and am just not sure how to figure it all out, but odds are that if I am struggling with it then other people will as well.
You probably have plans to simplify it, but is that something that is in the works for this release?

@jasonbiondo Regarding complexity -- I'll keep supporting easy-webpack, so if complexity is a turn off for you, you'll still be able to use easy-webpack along with Aurelia. However, many people expressed the need to understand and modify the underlying config, hence the default we'll be using direct configuration. On the other hand, I'll add more presets to the plugins so that configuration will be much shorter. In the end, when this is integrated into the Aurelia CLI, you will be able to choose whether the generator should make configs using easy-webpack presets or inline the config.
First release will still be marked "experimental" and it'll stay that way until we have ironed out any major bugs and addressed simplicity and configurability concerns, such as those expressed by yourself.
I don't recommend integrating this into major projects before we get the new PLATFORM.moduleName plugin working.

@niieani I have added a small plugin to find html views by convention (i.e. extension swap) to my setup:
https://github.com/jods4/aurelia-webpack-build/blob/master/demos/02-Traced_deps/webpack/ExtensionDependenciesPlugin.js
With this I could remove my globbing plugin, as all dependencies are properly traced.
My future plans:

Have a look at the module renamer, which looks complicated to me;
Consolidate the plugins a bit;
Remove list-based-require-loader when Aurelia itself declares its dynamic dependencies through PLATFORM.moduleName();
Create an über-plugin so that all the different pieces that make this work can be set up in one fell swoop.

Things not worked out yet:

Do we need some globbing for dynamic dependencies? If yes, how should it work?
How to define splitting points? How will it work with Aurelia loader?

@jods4 your plugins seem like an interesting approach. Below are some of my comments:

a potential problem: you are requiring the internal fs module, which is incorrect for any Webpack plugins or loaders. The reason is filesystems can be replaced/mocked, dynamic or in-memory, and Webpack provides an interface to use the internal fs module, available to the loaders and plugins
the two problems you mentioned as "not worked out yet", I have already thought about extensively. The reason I introduced PLATFORM.moduleName(name, {  configuration }) is so that we can configure dynamic dependencies, including split-points and lazy-loaded ones. aurelia-loader-webpack handles those cases natively (i.e. detects bundle-loader uses, as long as they're named accordingly by the module renamer)
Every dependency inclusion should have a post-processing step just before adding the dependency, one looks for centralized bundle configuration and depending on that makes the require lazy (or not), and places it into the correct chunk. The reason is that we might want to be able to use centralized configuration, which overrides the configuration provided via PLATFORM.moduleName(name, { configuration }) (useful for various reasons, including testing)
As for globbing, I think it should work the same way as for Webpack's native require.context command, only ported to the PLATFORM.moduleName with the option to override the regex in the second parameter of the configuration.

@niieani Let's track each point separately, it'll be easier. I created an issue for each in https://gituhb.com/jods4/aurelia-webpack-build/issues, which you may want to watch for now.
In particular, I'm not sure I understand your third comment, see jods4/aurelia-webpack-build#3.

@niieani There's now an alternative plugin to preserve module names in webpack output.
It certainly does less than yours, which I didn't understand fully, but it's enough to get my demos working.
It only preserves dynamically loaded modules (identified by PLATFORM.moduleName() or extensions conventions or globbing) and don't care renaming the rest, which will have the usual webpack index.
I have a few issues to solve, though:

generating relative module names inside library packages (e.g. aurelia-templating-resource) is currently hacky.
the entry point is annoying because it is defined inside my main index.html file. This is where aurelia-app lives but it's not caught up by the HTML analyzer because it's outside the compilation. I fixed this by adding a PLATFORM.moduleName('main') inside my main.ts file itself. This is not particularly good 🙁
no support for code splitting (i.e. lazy loading) but that's the next step!

@niieani any update on the last plugin to be made?  My 0.chunk is still huge until this becomes available and I can switch to incorporate lazy loading.

@niieani I have added support for code splitting, by passing a chunk name to PLATFORM.moduleName('module', 'chunk').
There is a new example in my repo with 2 pages that are in their own chunk each.
At this point I think that I have everything in experimental but working form. The only thing I don't support is expressions in PLATFORM.moduleName. I think that they have very limited use-cases so I'm not prioritizing that at the moment.
What I want to do:

some clean-up and refactorings;
some plugins consolidation;
package everything under a single AureliaPlugin to make consumption easier (not that it's particularly complicated, but that are a bunch of plugins involved).

@jods4 I have reviewed your PLATFORM.moduleName implementation and its awesome in terms of splitting the code.  Are you going to be the one building this out for the aurelia team or is it something you did for fun?

I have the same error during bootstrapping as @Vheissu mentioned above. The reason seems to be, that webpack eliminates the export from the initialize function in aurelia-pal-browser. There's only a comment in the bundle: "/* unused harmony export initialize */". I manually added the export in the bundle but then I've got another issue:
Uncaught (in promise) TypeError: Aurelia is not a constructor
    at config (aurelia-bootstrapper.js:127)
    at handleApp (aurelia-bootstrapper.js:123)
    at aurelia-bootstrapper.js:157

The Aurelia variable is undefined. The assignment should happen here:
return loader.loadModule(frameworkName).then(function (m) {
    return Aurelia = m.Aurelia;
});

But m is an object with these properties:
{
    a: lazy(keyValue), => Function
    get a: (),
    b: inject(), => Function
    get b()
}

Does anybody know, how to solve these two bugs?

@jasonbiondo No idea! :laughing:
Right now I'm personally interested in getting webpack to work and having something that is simple and understandable without bringing in too many tools / frameworks / libraries (I like to set up my projects manually, call me old-fashioned).
I talked with @niieani briefly and there is certainly interest to take over/re-use some of my work. Nothing concrete yet.
Overall I would say Aurelia webpack support is experimental right now. There have been several implementations already and this is still in development. Support is coming "soon-ish" but I would say it's a little early to jump in, unless you are prepared to work with experimental stuff (no doc, changes expected, some bugs, etc.).

@code-chris the problems you and @Vheissu describe occur on Windows only. There must be a bug in the module resolution logic somewhere. I will tackle it when I have some time to again focus on this PR.

@niieani Thanks!

@niieani Thanks for working on this experimental skeleton.  I've had issues running this project on Windows. The first obstacle was using environment variables like $LOCAL in bnr:
$LOCAL/ doesn't work at all on Windows. So, I replaced $LOCAL/ with blank to get "npm start" working
After removing $LOCAL/, I faced the same issues that @code-chris and @Vheissu are facing now. The good news is I have a CentOS 7.2 HyperV VM on my Windows 10 laptop where this project works without any issues :) I can continue using this experimental project on *NIX systems until it starts working on Windows. It looks like switching from cross-env to bnr has issues at the NPM scripts level but the other error "Uncaught (in promise) Error: Unable to find module with ID: aurelia-pal-browser" is a real blocker.

@niieani My team has tried adding in a less loader to load our less files to the experimental branch but we are hitting this error:
Warning: Keeping '-!/Users/jasonbiondo/Sites/trekeffect-app/node_modules/less-loader/stringify.loader.js!/Users/jasonbiondo/Sites/trekeffect-app/src/application/contributors/less/0.less' without the loader prefix '/Users/jasonbiondo/Sites/trekeffect-app/node_modules/less-loader/stringify.loader.js'. Explicitly silence these warnings by defining the loader in MappedModuleIdsPlugin configuration
howdy application/contributors/less/1240.less
Even though we have defined it via:
new MappedModuleIdsPlugin({
appDir,
prefixLoaders: [
{loader: 'bundle-loader', prefix: 'async'},
{loader: 'expose-loader', prefix: 'expose'},
{loader: 'css-loader', prefix: false},
{loader: 'less-loader', prefix: 'less'},
{loader: 'style-loader', prefix: 'style'},
{loader: 'html-webpack-plugin/lib/loader', prefix: 'html-webpack'},
],
and also have it references as
{
test: /.less$/i,
use: [
'style-loader',
{ loader: 'css-loader', options: { importLoaders: 1 } },
'less-loader'
],
issuer: {
test: /.[tj]s$/i
}
},
in const aureliaApplication: CFG
Can you explain what is causing this or how to fix it?

I get the error Unable to find module with ID: aurelia-pal-browser" just like @rajajhansi. I tried the solution reported in https://github.com/aurelia/loader-webpack/issues/28 by mdurling but that didn't work for me. I'm on windows too. What can I do to resolve this issue?

@jasonbiondo The warning seems to be coming from less-loader/stringify.loader.js, not the less-loader itself. You'd need to add that one too to silence that warning, or simply ignore it.
@techmind-git I haven't yet had the time to tackle Windows issues. I'd like to get Mac OS X and Linux working first and only then focus on fixing Windows support, since that's always a bigger challenge.

@rajajhansi Another interesting option that could avoid the weight of a VM, is WSL (windows subsystem for linux). That's how I'm planning to play with these bits until Windows solidifies

@niieani aurelia-loader-webpack.js:199 Uncaught (in promise) Error: Unable to find module with ID: resources/index Any idea how to fix this?
from
 aurelia.use
  .standardConfiguration()
  .feature(/* @import */ 'resources’)

@jasonbiondo do you have a file named resources.js or resources.ts in your src directory?
As for the other thing, I was referring adding that stringify loader to the list of prefixLoaders.

@niieani Some news about the plugins in my repo:

I made them work with webpack 2.2 rc4;
I cleaned them up a bit and polished the apis;
I added an encompassing AureliaPlugin that does most of the configuration for you. Config wasn't hard but there were too many plugins involved in my opinion.

I think it's shaping up nicely.
Following our discussion in gitter, only basic features are supported for now: precisely trace dependencies and code splitting.
I am still unsure what extra features are actually useful and whether the are best done as extensions to moduleName api or independently.
@jasonbiondo decided to give it a try on his medium-large app (including code splits). I think that was a good real-life test that goes much further than my basic demos. After using the correct version of everything (cough cough), only 2 problems popped up:

aurelia-infinite-scroll does not declare its dynamic deps (aurelia.build.resources or otherwise).
aurelia-authentication uses aurelia.build.resources but it didn't work as webpack couldn't resolve the files on disk. Not sure where the problem lies and I didn't want to spend time debugging this as the plan is to get rid of aurelia.build.resources in the new build.

I was happy that it worked so well on first try. What it also teaches me is that the transition will be a little painful for early adopters until all aurelia libs out there properly describe their deps. Maybe we'll need to step up our support in both runtime and build errors so that root causes are easily discoverable. Problems can be fixed in several ways without updating the lib, but it can be slightly tricky.

@niieani overall @jods4 is awesome and helped me get the code splitting working nicely.  The only issue I face now that my main.js initial chunk is 1.5mb for prod without it being gzipped.  I've done some reviewing of the stats and it looks like I need to trim down my library dependencies etc.  Anyone who wants code splitting needs to check out @jods4's demos.  This however, should really be integrated fully into aurelia.  What I did was I ended up using a combination of jod's config and the new experimental webpack config.  The blended combination let me have both code splitting while supporting multiple dev environments.

Fantastic work @jods4. Let's sync together on Gitter whenever you're free to chat and get this out to the world!

There's any plans to add HMR working?
On 14 Jan 2017 11:17, "Bazyli Brzóska"<EMAIL_ADDRESS>wrote:

Fantastic work @jods4 https://github.com/jods4. Let's sync together on
Gitter whenever you're free to chat and get this out to the world!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-272617794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5o5SjZXRnKOtPSGKCp1BQ41r9Fil85ks5rSK6ugaJpZM4Kw1ol
.

@nmocruz HMR should work out of the box in this PR.

ok, I noticed that aurelia-pal-browse is not being loaded by webpack, so I added it manually by including it into main.ts. Now i get the _

'palModule.initialize is not a function'

on app startup.

@cluka had this as well once and it was a duplicated aurelia-pal module in the webpack bundle. Basically, convoluted node_modules created dependencies two 2 different aurelia-pal instances, which typically creates the error you quote.
One way to be sure is to look at your bundle contents for duplicates (webpack --display-modules).

@jods4 If I do webpack --display-modules it throws exception in ts-node:

TSError: ⨯ Unable to compile TypeScript
Cannot find type definition file for 'jest'. (2688)
Cannot find type definition file for 'node'. (2688)
Cannot find type definition file for 'webpack'. (2688)
at getOutput (C:\Users\Administrator\Downloads\skeleton-navigation-webpack-experimental (1)\skeleton-navigation-webpack-experimental\skeleton-typescript-webpack-experimental\node_modules\ts-node\src\index.ts:312:17)

if I run npm start, I see multiple (11 to be exact) aurelia-pal modules being passed to RewriteModuleSubdirectoryPlugin function in webpack.config. Also there is this error:

Error: Multiple modules with the same ID: 'events'.

Now I'm not good at javascript so I don't know what's happening here. I see that there are problems on Windows OS, and because I'm working on Windows I would just like to help devs locate the problem source. So I'm reporting here the problems I encounter.
P.S. Is there a way I can debug aurelia-loader-webpack and other aurelia libraries in Typescript (not javascript) using Chrome? I can't find any map files.

@cluka the first part looks like your TS compilation is failing. And by the look of it because of missing type defs.

I have put together a code splitting demo which is a combination of @niieani 's work in the experimental branch but also includes @jods4 's plugins.  I made this demo to give back a little bit to the community, but to also try and solve one core issue in the build I have put together.  You'll notice if you clone it that code splitting works really awesome right out of the box, but that image loading via the file loader and url loader doesn't seem to be working properly.
If you run a production build via: npm run build:prod you'll see that the images do not get pushed into the /dist folder.  @niieani I was hoping you can tell me what the issue is because I have a feeling I am missing something key from your configuration in order to make this work.
https://github.com/jasonbiondo/aurelia-code-splitting-demo
Let me know if anyone can point me in a direction on this.  I'd like to figure out now how to optimize images and load them properly in the app and the currently loaders in my webpack config don't seem to be doing anything.

I finally resolve my problem on windows and those are the steps to fix it:

in package.json replace every "$LOCAL/" with ""  (this resolved the $LOCAL error)
I removed  "node", "webpack", "jest" from "types" collection in tsconfig.*.json files in root dir (this solved the webpack compilation error :

Unable to compile TypeScript
Cannot find type definition file for 'jest'. (2688)
Cannot find type definition file for 'node'. (2688)
Cannot find type definition file for 'webpack'. (2688)

I had to install webpack-dependency-suite (npm install webpack-dependency-suite --savedev)
I deleted the test folder (webpack was throwing errors in tests so I deleted them)

After that I was able to run npm start and then the application launched in the browser. BUT then I got the infamous error:

Unable to find module with ID: aurelia-pal-browser

After hours of debugging, I have found no errors in aurelia loader code. It seems that this is error of the webpack/configuration. I don't know why it works on linux, but on windows it does not add "aurelia-pal-browser" to the modules collection.
To solve this I added this:
5. In webpack.config change line 350 from:

include: [/*srcDir, */ aureliaModules],
to
include: [nodeModules, aureliaModules],

Now when I do webpack --display-modules it shows aurelia-pal-browser along with some other modules. And the application starts without error on npm start.
@jods4 @niieani  Hope this can help pinpoint where the true error is on windows. In the meantime @Vheissu @code-chris this is a temporal solution.

@cluka thanks for debugging. It seems the webpack-dependency-suite plugin related to tracing aurelia.build.resources does not work properly on Windows, hence aurelia-pal-browser is not automatically added.

@jods4 Should this be merged now?

@EisenbergEffect not yet. This particular PR is using a set of plugins I've written, most of which were simplified and re-implemented by @jods4. We'll first need to get the new webpack-plugin using his plugins, from @jods4, we'll then update the PR and we'll be able to merge, perhaps even replace the original webpack skeletons, since the new setup should be battle-tested once the plugins land.

@niieani Can you share information how can I debug the webpack-plugins and configuration. I would like to help on this, but I need to know how this works internally. Or maybe do you have a link where I can read about how to debug webpack build and plugins?

I'm starting a new project based on Aurelia pretty soon. I'm loving the dev experience provided by this PR, but I don't think I can convince my colleagues to use this experimental branch. Would you recommend waiting for this to be merged, or can an existing project be easily updated later on to include these features?

@jmezach we will provide a very simple upgrade step to get the new Webpack capabilities. As for other features (e.g. Testing), you'd need to backport them manually.

@niieani, We have started our project in Windows. We are blocked by this solution not working on Windows.  Would you recommend using the workaround provided by @cluka until a working cross platform webpack.config.ts is ready?

@rajajhansi you could try and use one of @jods4 demos as a base, as long as you don't mind refactoring your configs after the final one is released. However, @jods4 is fairly close to completing his work, so you can expect an update with Windows support soon.

@niieani Thank you for the prompt reply. We're currently using @cluka's solution. We will look into @jods4 demos and integrate his changes. I guess it will be fine for sometime because we can continue working. Thank you, @cluka , @jods4 for fixing these issues.

@rajajhansi My solution is only for debugging purpose and it allows you to start the skeleton but nothing more. I wouldn't recommend you to use it for real world application. The solution is incomplete because you will get errors when you try to add another aurelia plugin. It will not work. The problem still remains that the webpack does NOT find all modules on windows on this branch. I would wait a few more days like @niieani said, for the final version to be complete. You can use the main branch until then.

@EisenbergEffect  @niieani Are these PR's dead?  Am I the only one wondering what is taking so long to get this merged?  This has been in development for months.

@jasonbiondo Far from dead. 😄  As you can see from the first post, we're still working on the last remaining task ("Write a Webpack plugin...") to ensure its both really simple and painless to upgrade, and that the new system isn't experimental anymore, but in fact, production-ready.
The new plugin is ready and now in review. @jods4 did an amazing work simplifying the system and testing it with some community members on their larger projects.
We are literally only days from getting this awesomeness released!

Just curious if anyone has tested this with wallabyjs and knows if it will work out of the box?

I would like more early adopters to test these new plugins.
As @niieani says the plugins are ready to be tested but there is no documentation at all for now, which makes it a little bit difficult. If you feel courageous there are a few demos here:
https://github.com/jods4/aurelia-webpack-build/tree/master/demos
I have to write some "Getting started" because although the webpack config is trivial, there are a few assumptions and things you need to know as you will run into a few hard edges, especially with 3rd party libraries.

@jods4 I will be adopting it as soon as it comes out - but only when there are sufficient surrounding docs for the upgrade process, I unfortunately cannot commit to testing them out if I have to piece together what bits I need (as I only want to inherit the parts I actually require).
Let us know when the "Getting started" docs you're speaking about are due to drop and I'll read through them.

@jods4  I was trying to integrate your plugin with the aspnet/javascriptservices, replacing the old one with your.
I changed package config to use the branch v2. I got some errors, is not finding some module
ERROR in ./~/aurelia-bootstrapper/dist/native-modules/aurelia-bootstrapper.js Module not found: Error: Can't resolve 'main' in 'F:\projects\tudu\node_modules\aurelia-bootstrapper\dist\native-modules'  @ ./~/aurelia-bootstrapper/dist/native-modules/aurelia-bootstrapper.js

@nmocruz aspnet/javascriptservices is something I want to test and integrate as well, but I haven't had the time to yet. Let me know how it turns out!
The main dependency is automatically added to bootstrap your app -- this is one thing I need to write about. :(
It all depends how you bootstrap your app. A common way is to have aurelia-bootstrapper as entry point and have some aurelia-app attribute in your main html. AureliaPlugin adds this starting point to aurelia-bootstrapper, and it adds main by default.
This is how the demos work and this explains the not found main dependency of aurelia-bootstrapper that you saw.
If you bootstrap like that, but not with main, you can configure it:
new AureliaPlugin({
  aureliaApp: 'index-or-start-or-whatever'
})

If your startup works differently, you can set aureliaApp: undefined and no extra dependency will be added to your entry point.

Another pain point I expect you to encounter and want to document is 3rd party libraries.
The idea moving forward will be that libs use PLATFORM.moduleName the same way you have to in your code and everything just works magically.
In the meantime, this is of course not the case so you'll need to add those dependencies manually in your build config. You can easily do this with ModuleDependenciesPlugin from aurelia-webpack-plugin. Here's how I'm actually doing it for Aurelia itself, until it's patched and published:
https://gist.github.com/jods4/600ded3c31b48c4d1a9e03855d54e1e2
(in the meantime this is what aurelia-core-dependencies does in the demos).
Feel free to ping me in gitter if you need help.

@jods4 I changed to new AurelaPlugin( {includelAll: "ClientApp"} ) it solved the issue with resolving the main. With that webpack builds, but when I run the app, the aurelia-loader-webpack is failing to load the module 'app/components/app/ap' in aurelia.setRoot(PLATFORM.moduleName('app/components/app/app')

I did write enough informations to get started (I think). Start here: https://github.com/jods4/aurelia-webpack-build/wiki
Feedback is welcome. If you run into problems you can open issues on my repo. As this is brand new, I'm pretty sure we'll encounter some use cases that we didn't anticipate.

@jods4
One issue I immediately ran into was the usage of aurelia.use.features.
Steps to produce the issue:

Make a directory named components under the src directory
Add a file in the components directory named index.ts
Add the following to the newly created file:

import { FrameworkConfiguration } from 'aurelia-framework';

export function configure(config: FrameworkConfiguration): void {
    config.globalResources([]);
}

Modify your main.ts file to look like this:

export function configure(aurelia: Aurelia) {
    aurelia.use
        .standardConfiguration()
        .developmentLogging()
        .feature('components')
        .globalResources('converters/upper');
    aurelia.start().then(() => aurelia.setRoot());
}

This mechanism should work perfectly fine, as it is described in this article, however the browser doesn't render the page and has the following console error:
Uncaught (in promise) Error: Unable to find module with ID: components/index
    at WebpackLoader.<anonymous> (bundle.js:17054)
    at step (bundle.js:16892)
    at Object.next (bundle.js:16873)
    at bundle.js:16867
    at 68.__awaiter (bundle.js:16863)
    at WebpackLoader.68.WebpackLoader._import (bundle.js:17010)
    at WebpackLoader.<anonymous> (bundle.js:17119)
    at step (bundle.js:16892)
    at Object.next (bundle.js:16873)
    at bundle.js:16867

@MikeBull94
You need to wrap your module names in PLATFORM.moduleName() (or use includeAll).
But then .feature() is a vexing API and won't work anyway. This is called out on this page:
https://github.com/jods4/aurelia-webpack-build/wiki/Managing-dependencies
The trick is that .feature(x) doesn't require x but x/index.
We are debating what the best way to handle that is.
In the meantime the page above also gives you a workaround: add a statement `PLATFORM.moduleName('components/index'); somewhere in that file.

@jods4 What change introduced this requirement? The old aurelia webpack plugin never required me to unnecessarily repeat the import.

@MikeBull94 The new plugins have a completely different design than the old ones.
They are much simpler and integrate into the natural "webpack" way of doing things.
If by "this requirement" you mean moduleName:
Note that the old plugins were dependent on aurelia.build.resources in package.json. It's more or less the same, but worse (it doesn't support code splitting for example).
If you mean .feature(), I am actually not sure how the old plugins dealt with this @niieani ?

@jods4

Note that the old plugins were dependent on aurelia.build.resources in package.json

I never had to do this at all? See: [1] [2].

@MikeBull94
You can also use includeAll to just put all your files in your build (but not 3rd party libs).
That's quite similar to what the old plugin did.
In that case you don't have a precise dependency tree and you loose some advanced features, like code splitting or tree shaking.

@jods4
I am using includeAll: "src" already, and the index.ts file I was talking about lives under src/components/index.ts.
So surely it should work and would allow me to avoid having the duplication with PLATFORM.moduleName?

@MikeBull94 Yes it should work.
I assume that in your webpack options you have:

resolve.module: [ "src" ]
resolve.extensions: [ "ts" ]

What's your webpack --display-modules output regarding this file? I assume it's there but with an incorrect id?
Ping me on gitter it's going to be easier than github if you want to debug this.
Note that PLATFORM.moduleName is not a duplication, just a wrapper (with the exception of .feature() at the moment...)

@jods4
This is using your "demo 01 no splits", so yeah I have both of the things you just listed. All you need to do to reproduce this is clone your first demo and add a feature as I described in the reproduction steps, and you'll get the exact same error as me.

@MikeBull94  I just did and it worked.

Not sure what I was doing wrong - just repeated it from scratch and it works thanks @jods4

@MikeBull94 no problem.
At this point this is still brand new so we welcome every early tester and their feedback (whether it works or not). There has been a couple early users that had success with real projects but I'm sure there are still some corner cases to identify (e.g. .feature() was a late find).
Until we officially publish this, if you are trying it out and have problems please get in touch with me on gitter.

@jods4 I tried it and it works out of the box. The only problem I encounter with your sample is that HMR works with HTML views, but not when I change a TypeScript file, e.g. app.ts

@arjendeblok Thanks. HMR works with typescript as well... app is just a bad choice ;)
aurelia/hot-module-reload#9
See also
aurelia/hot-module-reload#8

@jods4 HMR does not work with the upper.ts file in the converter folder also. Nor does it work with the page-hello.ts file.

@arjendeblok HMR is experimental and will remain so for at least a few more months. You're welcome to submit related bug reports to the HMR repo. For this PR I think it's more important to get a stable, fully-featured skeleton for Webpack. HMR is just the cherry on top of the cake - if it works, that's great, if not, we'll still release the skeleton and keep ironing out the HMR :)

@arjendeblok I know, the problem with upper is the second issue I linked: aurelia/hot-module-reload#8.
When I looked into that, it seemed to me that the limitations/issues happened at runtime. For some reason aurelia-loader doesn't go through the correct "hot" loading path for the entry point and global resources. But this looks unrelated to our new webpack setup as everything seems to be in the bundle like you'd expect it to.
Aurelia hot-module-reload would be the right place to file issues about HMR.

I have implemented a miminalistic starter kit that uses the latest version of the plugins, can be located here.
It's looking great so far, however I have an issue with my E2E Protractor tests. They seem to open the webpage perfectly fine during the test, but the individual tests themselves (i.e. the it functions) aren't running - then eventually Protractor times out and concludes that a failure occured.
If anyone can shed some light as to why this might be occurring it would be great. The implementation is using the latest version of the aurelia-protractor-plugin and aurelia-testing.
The unit tests are running perfectly fine with Karma + Jasmine, and the rest of the project seems fairly stable.

After speaking with @niieani we found the issue regarding the protractor plugin. PR for the fix is here. This is the only outstanding issue I've seen with the new plugins.

Excellent!
On Feb 5, 2017 9:55 AM, "Michael Bull"<EMAIL_ADDRESS>wrote:

After speaking with @niieani https://github.com/niieani we found the
issue regarding the protractor plugin. PR for the fix is here
https://github.com/aurelia/protractor-plugin/pull/4. This is the only
outstanding issue I've seen with the new plugins.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-277536241,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIBnYG97V9SHCtZXCAz3czptMDLsTh6ks5rZg0JgaJpZM4Kw1ol
.

only outstanding issue I've seen with the new plugins... The project itself runs perfectly, and both unit & E2E tests have no issues at all!

@niieani Are we good to merge this after we release the new webpack plugin? or is there more work that needs to be done here first?

@EisenbergEffect it's worth noting that the example posted above is reliant upon the https://github.com/jods4/aurelia-webpack-build.git#aurelia-core-deps repository from @jods4. Would be nice to have this published on npm too as currently I had to add a dependency on the repo itself.
Also, I would suggest adding a new release of the aurelia-protractor-plugin to the checklist in this issue, as we pushed a fix for it that occurred as a result of the new webpack-related plugins.

@michaelbull aurelia-core-deps is only a stopgap measure. It won't be necessary at all when the next Aurelia release is published.

@EisenbergEffect I'll need to update this to use the new aurelia-webpack-plugin once it's published and possibly add the JS version. Actually I might drop the old webpack skeleton and replace it with this one, since it's fairly stable by now, and users can still access the old skeleton releases.

@niieani let me know if you have questions or remarks while updating the skeleton.

Hey, this is great work and I'd like to echo everyone else when saying thanks and can we try to push this over the line? Like many others the ability to stage components on windows is a massive thing for my current team and until this capability is in place we continue to incur the dreaded tech debt! :)

We've just switched our application to use the new webpack configuration based on this PR and almost everything seems to be working. However, with the previous version we could put a JSON file next to the index.html in the root folder and we could fetch that in our application when using the webpack-dev-server. With this version however we get a 404. Is this a known issue?

@jmezach The new build is pretty much "just plain webpack".
If you expect a static file to be served by webpack-dev-server it must be in your devServer.contentBase. Also you may tweak the URL that matches your static folder(s) with devServer.publicPath.
What is your setup like?

Well, we had an application that was created based on the original skeleton
two and a half weeks ago. Now we've copied the package.json,
webpack.config.ts and tsconfig..ts from this version over our existing
files. Then had to install some additional packages, add / @import */ in
some places and add an import 'aurelia-bootstrapper' to the main.ts and we
are almost up and running again now. Except for getting the 404 on static
files.
Looking at the contentBase setting in the new skeleton it seems to be set
to the baseUrl. Shouldn't that be a path then?
On Tue, 14 Feb 2017, 21:41 jods<EMAIL_ADDRESS>wrote:

@jmezach https://github.com/jmezach The new build is pretty much "just
plain webpack".
If you expect a static file to be served by webpack-dev-server it must be
in your devServer.contentBase. Also you may tweak the URL that matches
your static folder(s) with devServer.publicPath.
What is your setup like?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-279829358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABKzEc59J2fHIaWicS8z9ZxrYY7MalAWks5rchGJgaJpZM4Kw1ol
.

@jmezach
I am not really following your exact issue but I know that I have run into similar issues before and the solution was to use the webpack config's output.publicPath. Not sure if that will help you but I thought I would post it anyway.

@jmezach Sorry, maybe I misunderstand you because there were discussions about several versions in this thread.
Are you using the code from this PR? If so forget what I said, maybe @niieani may help you.
If you use the<EMAIL_ADDRESS>RC that was mentionned several times in this thread, then that's what I was referring to.
Please note that the latter is going to become the official way to build Aurelia applications with Webpack.
This PR will probably be abandoned or refactored to take that into account. I wouldn't spend time trying to get it to work if I were you.

Ah, I see. I wasn't aware of that.
Are there any examples of how it should work with the<EMAIL_ADDRESS>RC package then?

@jods4, @niieani - Like many others, I have been waiting for a new Webpack-skeleton project using this webpack.config.ts and the new aurelia-webpack-plugin that runs on Windows. I hope that it is not too far away in the future since we use a version of webpack.config.js using easy-webpack and a few other hacks to continue our development without stalling.

@jmezach If you want to give it a try, there is information to get started in this wiki
https://github.com/jods4/aurelia-webpack-build/wiki
There are some working setups in the same repo.

@jods4 Thanks for the wiki link I've had a v quick scan through and will go back over it in detail again later but wanted to clarify that if I look to follow the steps outlined that I "should" be able to stage components inside unit tests on windows?

@mike-suggitt I'm not sure I understand what you mean by "stage" components. But this build works on Windows, yes.

@jods4 Sorry I'm just meaning the use of StageComponent to fully render an Aurelia Component for unit testing components and their views as documented in https://github.com/aurelia/testing/blob/master/doc/article/en-US/testing-components.md. Thanks

@mike-suggitt I see.
I don't know. aurelia-testing is one of the few remaining core Aurelia libs that have not been tested with the new build (see aurelia/pal#21).
There's a good chance that it works, but then there's Murphy's Law.
If you try it let me know how it goes. If you have encounter issues ping me on gitter and I'll try to help.

@jods4 First of all I must say that aurelia-webpack-plugin version 2.0 looks very promising.
I've start using it in my project, but I encountered a small problem. I have  few components that are using named slots. Build get successfully, but I get an error at run time
Do I miss something or this is an issue?
I must specify that if unnamed slots are used this is working fine.
Uncaught (in promise) Error: Error invoking SlotCustomAttribute. Check the inner error for details.
Inner Error:
Message: key/value cannot be null or undefined. Are you trying to inject/register something that doesn't exist with DI?
Inner Error Stack:
Error: key/value cannot be null or undefined. Are you trying to inject/register something that doesn't exist with DI?
    at validateKey (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8241:11)
    at Container.get (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8438:5)
    at Container.elementContainerGet [as get] (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:2294:15)
    at Object.invoke (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8290:31)
    at InvocationHandler.invoke (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8261:166)
    at Container.invoke (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8525:23)
    at ProviderResolver.get (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:2239:72)
    at Container.get (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:8464:21)
    at Container.elementContainerGet [as get] (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:2294:15)
    at HtmlBehaviorResource.create (file:///C:/work/sandbox/webpackbuild/aurelia-webpack-build/demos/02-Traced_deps/dist/bundle.js:4246:56)
End Inner Error Stack

@ovi2 To avoid spamming the many subscribers of this thread, I moved your question to jods4/aurelia-webpack-build#10.

@jmezach I'll be updating this skeleton to match the new set of plugins based on this PR, which are much more simplified in usage. I've been hit by cross-platform compatibility of other parts of this PR, hence the delays in updating (I'm working on this locally), but as @jods4 mentioned, you may all try to use his simple skeletons as a base for testing until we release aurelia-webpack-plugin 2.0.

@niieani Ok, will it differ much from the @jods4  skeleton? I mean, if I use @jods4 skeleton, will there be breaking changes when the new skeleton You are working on is published?

@cluka it will be a more complete skeleton, i.e. will include both unit testing and e2e testing, as do other skeletons in this repo. Shouldn't differ much other than that.

@niieani A rough ETA? Eagerly looking forward to this one. Thanks for the great work

@jack4it I don't like rough ETA's since the last one was that we wanted to have this out before the end of December. We're now aiming to do this before the end of February.
We simply want to polish this as best we can before we announce the release, so we avoid all the problems that happened with the initial Webpack support.

@niieani
will server side rendering be a feature that can be enabled or disabled?

looking forward to this :)

❓ Should concurrently be included in devDependencies?
$ npm run e2e

# ...

> concurrently --success first --kill-others "bnr e2e:start-when-ready" "bnr webpack:e2e"

sh: concurrently: command not found

After npm i -D concurrently:
[0] 5 specs, 0 failures
[0] Finished in 3.6 seconds

I updated the dependencies to:
 @types/jest                       ^16.0.4  →  ^18.1.1
 @types/jsdom                      ^2.0.29  →  ^2.0.30
 @types/node                        ^7.0.0  →   ^7.0.5
 @types/webpack                     ^2.2.0  →   ^2.2.6
 aurelia-fetch-client               ^1.1.0  →   ^1.1.1
 aurelia-polyfills                  ^1.1.1  →   ^1.2.0
 aurelia-router                     ^1.1.1  →   ^1.2.0
 awesome-typescript-loader  ^3.0.0-beta.18  →   ^3.0.7
 enhanced-resolve                   ^3.0.3  →   ^3.1.0
 expose-loader                      ^0.7.1  →   ^0.7.3
 file-loader                        ^0.9.0  →  ^0.10.0
 html-webpack-plugin               ^2.26.0  →  ^2.28.0
 jest                              ^18.1.0  →  ^19.0.1
 protractor                         ^5.0.0  →   ^5.1.1
 ts-jest                           ^18.0.1  →  ^19.0.0
 ts-node                            ^2.0.0  →   ^2.1.0
 typescript                         ^2.1.5  →   ^2.2.1
 webpack                        2.2.0-rc.3  →    2.2.1
 webpack-dashboard                  ^0.2.1  →   ^0.3.0
 webpack-dev-server             2.2.0-rc.0  →    2.4.1

Everything is good, except for welcome.spec:
to be executed: $NODE $LOCAL/jest --no-cache
 FAIL  test/unit/welcome.spec.ts
  ● Test suite failed to run

@niieani we can perhaps start a simple project board for this? This thread is getting long 😅 Hard to tell what still needs to be done.

@sbolel I keep updating the first post with the remaining tasks. Right now we have two left.
To answer your question, yes, concurrently should be included. Anyway, I'll try to get rid of bnr and concurrently if possible, to make this more minimal.
@lmj0011 server-side-rendering will be done separately. You can see the demo of the feature in the ssr branch of this repository. Also, feel free to look at the implementation of the demo yourself. It's pretty simple and straight forward.

@niieano awesome, thanks for keeping the first post updated.
Is adding concurrently -- done in #744 -- still relevant or should we close that one?
I'd enjoy taking a stab at getting rid of concurrently.

Sorry @niieani .. but what is the exact reason for the delay in completing this merge?
What is the new aurelia webpack plugin is missing? Is it the Windows version that causes errors? Is it the unit testing that is still broken over some platforms? Or is everything working but you want to make extra sure everything is working without issues (battle tested)? Or is it the documentation since the old docs in the hub no longer reflects correctly the new changes? Or is it that you can't find enough time to work on it because of other engagements? Or is there any specific stubborn problem that you are facing in the code that perhaps you need some help from experts?
Sorry but the merge status / date is still vague. For many of us, this is one of the most anticipated update release specially for production deployment. Any clarity on this will help.
Thanks,
Yousuf.

There are several reasons:

We made a lot of changes to a lot of Aurelia libraries. We've had to review every change and merge those first. Then, we had to release each library. There is a dependency chain and so we're trying to do this carefully to make sure the semver compatibility is correct. This is in process now.
We also have to update our documentation. We can't launch this with the current documentation in place, because they are entirely different.
We're also trying to battle test this in a number of configurations on different OS setups, etc.

@niieani should we add this to the TODOs in the PR description:

[ ] remove bnr and concurrently dependencies

Since we merged #774, I don't want to forget to address https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-282141104

@sbolel thanks, I've added the task.

@swalters it's also tracked in aurelia/pal#21
If you want to help, you can submit a PR in aurelia-i18n to make it work, shouldn't be too hard (a few missing PLATFORM.moduleName most likely).

PSA: I know lots of people here were waiting for the new webpack plugins.
The updates to Aurelia have been published and the Webpack Plugin 2.0 RC has been published as well.
You can find updated demos here: https://github.com/jods4/aurelia-webpack-build
Some infos to get started are available here: https://github.com/jods4/aurelia-webpack-build/wiki
The announcement will follow later when we have more official documentation.
Thanks to all of those who've been early-testing this, a lot of your feedback has been integrated in the code to support as many scenarios as possible. 🙏

Fantastic work by @jods4, kudos!
I'll be updating the skeleton PR and merging it before we make the announcement. We're getting there!

any updates?

@niieani Any news on when this will be merged? Looking great!

@niieani @jods4 Can we get an ETA on when we can merge and release an official skeleton. As part of this I'd like to get the ASP.NET JavaScript services project updated with this work too. Please let me know. Thanks!

@EisenbergEffect I will try to get this together this or the next weekend. Not the ASP.NET part, though.

If we can get our own skeleton first, then we can rally some other contributors to help on updating the JS Services.

Any updates?

Any updates? Eagerly waiting for this release, especially JS Services.

@ClaudioNunes I thinks that is possible to update the to webpack plugin rc2. I didn't use it so much but it has almost everything needed to update this repo and other like aspnet/JavascriptServices.
It seems like aurelia team is busy in other things, maybe someone's with time could try to make a Pull request with this. I'm busy to.

Any updates on Webpack skeleton project with a working webpack.config.js using this new webpack-aurelia plugin?

🍸 It's done. 🍸

(please ignore the failing CI, it's a problem of the CI, not of the skeleton 👍 )

Whoop!! Once #782 gets merged, I'll help with the AspNet changes :)

Thank you @niieani!
Good job!

Appears to be broken - skeleton-esnext-webpack - downloaded from master, running on:
Windows 10
Node 6.9.4
NPM 3.10.10
Ran:
yarn install
yarn start

@niieani I am using skeletion-esnext-webpack, I see this line in webpack.config.js and I don't understand it:
module.exports = ({production, server, extractCss, coverage} = {}) => ({

I am used to module.exports = function(config) {, so this line threw me off. What does this line of code mean and how to turn on each flag (i.e production, server, ...etc)?
Also, I get failing unit-test cases on anything using async/await syntax. Do these lines need to be transpiled by babel?

{production, server, extractCss, coverage} = {} is destructuring the environment passed in from the command line (i.e. webpack --env.production --env.server).
I'll have a look at unit-test cases.

@niieani and team, awesome job here. I will be working to recreate my apps within this new skeleton over the next week. A few suggestions:
add these to the devDependancies:
"aurelia-tools": "^1.0.0",
"babel-eslint": "^7.1.1",
"eslint": "^3.15.0",
"html-hint": "^0.2.4",
"stylelint": "^7.8.0",
"stylelint-config-standard": "^16.0.0",
update the babelrc line 10 to be
"node": ["7.8.0"]
instead of "current"
Thanks!

@JoshuaVSherman, my first thought was: why would You like to add babel and eslint to typescript project? Because normally You would use either typescript compiler or babel (tough there were times when TS wasn't able to generate ES5 code for async, in which case TS->ES6->Babel served as workaround) and either tslint or eslint.
Are they related to running tests with jest?

sorry, i was replying without noticing that this was regarding typescript
I am not using typescript
On Tue, Apr 11, 2017 at 3:13 PM, atsu85<EMAIL_ADDRESS>wrote:

@JoshuaVSherman https://github.com/JoshuaVSherman, my first thought
was: why would You like to add babel and eslint to typescript project? Because
normally You would use either typescript compiler or babel (tough there
were times when TS wasn't able to generate ES5 code for async, in which
case TS->ES6->Babel served as workaround) and either tslint or eslint.
Are they related to running tests with jest?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-293371049,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMuN2McclL4_gwFinUmCVCCQSQQ6ExqFks5ru9DfgaJpZM4Kw1ol
.

--
Josh Sherman
www.joshandmariamusic.com

Is it only me that can't get skeleton-esnext-webpack working?

did you start all over or are you trying to incorporate changes into your
existing one?
I decided to just start all over and slowly merge my code back into the new
skeleton
On Tue, Apr 11, 2017 at 4:23 PM, stevies<EMAIL_ADDRESS>wrote:

Is it only me that can't get skeleton-esnext-webpack working?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-293389092,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMuN2AEoKDZtJLjWQOV99ene0PFSx6qGks5ru-E4gaJpZM4Kw1ol
.

--
Josh Sherman
www.joshandmariamusic.com

Starting from clean installation - see comments above from 2 days ago.

i'm using node 7.8.0
he added the missing bluebird dependancy to the package.json yesterday
https://github.com/aurelia/skeleton-navigation/blob/master/skeleton-esnext-webpack/package.json

I was able to update my projects with the latest releases, only thing not working is SCSS files, I get:
Error: Failed loading required CSS file: oss-resources/custom-elements/entity-select.css
    at fixupCSSUrls (app.bundle.js:2)
    at app.bundle.js:2

In oss-resources I have entity-select.ts, entity-select.html and entity-select.scss which is included in the template as <required from "./entity-select.css" as="scoped">. Index of oss-resources includes the custom element with PLATFORM.moduleName("./entity-select").
Do I need special configuration to import SCSS/CSS files?

import 'entity-select.scss'should work in the view-model.
But I'm really curious how to do this with <require>.. 😏

@Thanood I had the same issue and decided against more head scratching and added all of my scss imports to the viewmodel.
Not a real solution though..

Thank you @Thanood for the workaround, unfortunately I cannot change that module. Any way to fix this in webpack.config.ts? I tried with the ModuleDependenciesPlugin but somehow for CSS it's not working (tried entity-select and entity-select.css both).
@niieani is the plugin actually supposed to import template's <require> resources?

<require from="./entity-select.css" as="scoped">
you mean entity-select.scss, right?
With proper loaders config and<EMAIL_ADDRESS>it should work.

I am also seeing strange things with my CSS imports. What worked before is
no longer working. I had to inline a bunch of styles yesterday for my
aurelia-table
On Apr 21, 2017 7:35 AM, "jods"<EMAIL_ADDRESS>wrote:

you mean entity-select.scss, right?
With proper loaders config and<EMAIL_ADDRESS>it
should work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/skeleton-navigation/pull/714#issuecomment-296167978,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMuN2AwloM-Uei6j-ploVqiMbtBSvTS9ks5ryJRzgaJpZM4Kw1ol
.

@jods4 I use the .css file in the <require>, not the .scss as it worked before. I suppose I had wrong loaders before, I'll try with requiring the .scss if that should work.

@heruan support for .scss is very new. Be sure to not use style-loader.

Hm, in fact requiring the .scss I get this when bundling:
ERROR in<EMAIL_ADDRESS>Module not found: Error: Can't resolve './entity-select.scss' in './node_modules/@saiv/oss-resources/dist/main/custom-elements'
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS> @ ./src/main.ts
 @ ./~/aurelia-webpack-plugin/dist/aurelia-entry.js
 @ multi aurelia-webpack-plugin/dist/aurelia-entry aurelia-polyfills aurelia-loader-webpack (webpack)-dev-server/client?http://<IP_ADDRESS>:8081 aurelia-bootstrapper

with this loaders:
module: {
        rules: [
            { test: /\.tsx?$/,  use: [ "awesome-typescript-loader" ] },
            { test: /\.json$/,  use: [ "json-loader" ] },
            { test: /\.html$/,  use: [ "html-loader" ] },
            { test: /\.css$/,   use: [ "style-loader", "css-loader" ] },
            { test: /\.scss$/,  use: [ "style-loader", "css-loader", "sass-loader" ] }
        ]
    }

Any hint or doc on how to configure loaders for scss?

Module not found:
Error: Can't resolve './entity-select.scss' in './node_modules/@saiv/oss-resources/dist/main/custom-elements'

I don't think this is a loader problem. Where is entity-select.scss?

In the same directory where the view-model and the template are:
src/main/custom-elements
├── entity-select.html
├── entity-select.scss
├── entity-select.ts

and then
dist/main/custom-elements
├── entity-select.css
├── entity-select.html
├── entity-select.js

Since oss-resources is an external module, the SCSS is already compiled to CSS and this is where I get lost. Do I need to import the SCSS or the CSS in the <require> template element?

Yup.
Webpack is looking there ./node_modules/@saiv/oss-resources/dist/main/custom-elements, which seems correct.
But you have a *.css file there, not a *.scss!

oss-resources is a module which is compiled and used as a dependency of my app. So, it contains JavaScript and CSS, not TypeScript and SCSS. Then, what should I require in the template? I think it's correct to import the CSS file, but it's not getting included in the bundle anyway.

I got it working with the postcss-loader, reverting back to <require from="./style.css">.

If it's a lib you distribute and you don't want to impose a SASS loader to your users then you should consume CSS indeed.
The fact that we can now require SASS or LESS directly is especially interesting for apps source code, I think.

Locking this so that people don't get emails for any more comments. If you're having problems with the new skeletons, please open issues, write on Gitter or create questions on Stackoverflow.