How to config HtmlWebpackPlugin

[bigopon]

❔ Question

Link to sandbox: (https://codesandbox.io/s/p7km1z3jlx)

Your Environment

Software	Name/Version
Browser	Brave

I'm having difficulty making the example in the link above work. The way a normal Aurelia app works is an entry script pointing to module aurelia-bootstrapper, which does all the bootstrapping, and then find element with attribute aurelia-app to find what module it should use for application startup (which in the link above, it's main). I'm not sure what I need to do to have this setup done in Codesandbox way. Could I have some hints for this? I was looking at other framework setup but none seems to use HtmlWebpackPlugin, and it's pretty hard to find where the setup is for Angular, Vue, React, Preact, Svelte

[lbogdan]

Hey @bigopon , thanks for opening this issue! We'll probably need to add an Aurelia template, as it seems to be doing some low-level stuff. Cc @CompuIves .

If you want to fiddle around (and maybe add an Aurelia template), you can find the existing templates' configuration here: https://github.com/CompuIves/codesandbox-client/tree/master/packages/common/templates .

You can also take a look at #709 , which is a PR adding templates for CxJS and Dojo.

[EisenbergEffect]

@lbogdan We are thrilled about the potential of getting Aurelia on CodeSandbox. Once that's setup, we're going to start embedding it directly within our documentation and hopefully our home page as well. We'll also be blogging about it (and using it in our official blog too). It will be great for our community. In light of that, would you be able to assist us a bit more directly in getting the template built out? We've been looking at a few examples but we see a good amount of variation and we aren't sure what the various APIs and settings are doing. @bigopon is the team member that's investigating it on our side.

[lbogdan]

@EisenbergEffect Sure, I'll try!
@bigopon Can you please point me to an Aurelia simple app github repo?

[bigopon]

@lbogdan Thanks for helping!. I have 2 examples atm:

• Simple: https://github.com/questmetrics/aurelia-webpack-bare It's mostly nothing beside few basic stuff to get an Aurelia app up and running. It uses TypeScript, html-webpack-plugin, copy-webpack-plugin
• Full: A potential new shape of aurelia-cli generated project template https://github.com/chrisckc/aurelia-cli-skeleton-typescript-webpack (It's not much different with the current one, just some extra optimization). It uses: TypeScript, Sass, PostCSS, html-webpack-plugin, copy-webpack-plugin, extract plugin and few others.

I can also setup 2 repos for simple / full for JS. Are they good as examples?

[lbogdan]

@bigopon @EisenbergEffect

So it looks like Aurelia's underlying development infrastructure is complex enough to require using a server / container template. I've taken your first repo and adapted it to work inside a container sandbox (you can take a look at what I did to achieve that, it's quite simple). This is the route we went with all the other complex frameworks out there (gatsby, next, nuxt).

To make an informed decision, the current pros/cons with this approach are:

• pros
  • trivial to add an Aurelia server template to CodeSandbox (it would basically ran the same as in your local development environment - only in a container in the cloud - so it would support virtually any webpack configuration)
  • ability to run aurelia-cli inside the container running the sandbox (you'll have to fork my sandbox above to be able to open a terminal inside the container and run commands - ignore the "Connection Trouble" warning after forking, that was fixed in master)
• cons
  • slower startup time (as we have to start a container, install the modules, run webpack-dev-server etc.)
  • server sandbox limit of 5 per user (as containers are still beta and we want to keep the number of server sandboxes under control)
  • we're using yarn internally (I've seen you're using npm, as you have a package-lock.json inside your example repo)
  • no sync of external file changes (i.e. files added by aurelia-cli) to the sandbox (they won't appear in the file list, so you won't be able to see / edit them) <- this is actually our focus at the moment, and we plan to release this feature sometime next week
  • webpack HMR is not working, as it tries to connect to https://localhost:8080/sockjs-node/... <- this should be easy to fix in webpack config
  • later edit: people have to fork a server sandbox to be able to make changes (and, in turn, to be logged in) - so they won't be able to just play around anonymously in a documentation embed, for example.

Please let me know what your thoughts are about this.

[bigopon]

@lbogdan I feel it would require a much simpler version and preferably stay as plain as possible. For example, Html webpack plugin can be removed, if we know how to point index.html to the entry, copy webpack plugin is really needed as static resources can be loaded from CDNs, dynamic resources like CSS can still be bundled like normal. Aurelia webpack plugin can handle that I think. Npm / Yarn also wouldn't matter, as it was just to minimize amount of installations needed. So it would be nice we can have this kind of config to start with:

const { AureliaPlugin } = require('aurelia-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const path = require('path');

module.exports = {
  resolve: {
    extensions: [".ts", ".js"],
    modules: ["src", "node_modules"],
  },
  entry: {
    app: ["aurelia-bootstrapper"],
  },
  module: {
    rules: [
      { test: /\.ts$/, use: 'ts-loader' },
      { test: /\.html$/, loader: 'html-loader' }
    ]
  },
  plugins: [
    new AureliaPlugin(),
    // this can be removed if we can point to `dist/app.bundle.js` and run easily
    new HtmlWebpackPlugin({
      template: 'index.ejs'
    })
  ]
}

For your container example with the ability to have arbitrary webpack configuration, that would be the way to go for members who want to do everything in codesandbox. We probably want to have that too! But our main focus is to have first integration step done before we explore that option. cc @EisenbergEffect

[lbogdan]

The thing is that the client bundler is not webpack, but "webpack like", so it doesn't support webpack plugins out of the box (we would have to adapt AureliaPlugin to the bundler, which depending on what it does under the covers, could be quite complex). @CompuIves is the client bundler expert (as he completely wrote it 🙂 ), so I'll let him give you the achievability and pros/conf of the client template approach.

[bigopon]

@lbogdan Thanks for that. @lbogdan @CompuIves For the context, I'm not sure if it will help clarify anything, current I'm using 2 base projects:

TS https://codesandbox.io/s/1zk698l74
JS https://codesandbox.io/s/woz49l74y7

[jods4]

@lbogdan AureliaPlugin is actually made up of many smaller parts. Some might be easier to reuse than others.
Overall it is deeply integrated with Webpack internal structure (how modules and dependencies are represented internally) so if you are just "webpack like" on the surface, I guess AureliaPlugin not gonna work well out of the box.

[lbogdan]

Closing this, as (hopefully) it was solved with the adding of the Aurelia template. Please reopen if that's not the case and I'm in the wrong here.