cli: Installing normal Aurelia plugins, what Im I doing wrong?

Is there anything special wee need to do to make normal plugins work in aurleia-cli This is what I tried`:

  • 1: Forked the skeleton-plugin, incase Ive messed up what ever I have in my custom plugin.
  • 2: Installed “default esnext” app with aurelia-cli
  • 3: Installed plugin-skeleton : npm install git://github.com/vegarringdal/skeleton-plugin.git --save
  • 4: Added to main.js this: .plugin('aurelia-skeleton-plugin') under feature(‘resources’) line
  • 5: Added to aurelia.json
{
            "name": "aurelia-skeleton-plugin",
            "path": "../node_modules/aurelia-skeleton-plugin/dist/amd",
            "main": "index"
          },

But this didnt go very well, I get

Uncaught TypeError: h.load is not a function

and

Unhandled rejection Error: Load timeout for modules: template-registry-entry!aurelia-skeleton-plugin/hello-world.html_unnormalized2,template-registry-entry!aurelia-skeleton-plugin/hello-world.html,text!aurelia-skeleton-plugin/hello-world.html_unnormalized3,text!aurelia-skeleton-plugin/hello-world.html http://requirejs.org/docs/errors.html#timeout

Im sure there is a easy fix for this, so any hints would be great.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 18 (7 by maintainers)

Most upvoted comments

I would suggest to make this restriction more pronounced - I completely missed it and we as a team spent a lot more time trying to make our bridges to work with RequireJS.

Now, speaking of RequireJS: why was that chosen as the leading actor in aurelia-cli? Other than knowing that GistRun was developed that way, there were no hints about RequireJS so far.

Why asking this? Because aurelia-cli became the greatest hit in no time, and now all our bridge users keep asking why is it that we did not deliver aurelia-cli based creation of apps that use these bridges. Pretty unenviable position, I might say with a does of humor 😃

Just wanted to note that I’m trying to follow the Contact Manager Tutorial in the documentation, and hit this same issue. setting stub: false resolved the problem. Not sure if I missed a step somewhere, or if this is a problem that actually affects the tutorial.

Nope. There’s no problem with that. Setting stub to true just doesn’t embed the full text loader. If you need to dynamically require text, you will just want to set that to false. It’s absolutely supported both ways. Our HUB actually sets stub to false.

I have the same issue when trying to use my framework with the cli. i tried every suggestion but cannot get it to work.

if stub: true error is Load timeout for modules if stub: false error is src/../scripts/app-bundle.html HTTP status: 404

the project repo: https://github.com/adarshpastakia/aurelia-ui-framework/archive/skeleton-cli.zip

the readme file explain how its setup, basically i create an aurelia app using the cli, the update the contents of src folder and index.html from the skeleton project

I may have made some progress in this area. Whenever an .html file of a plugin gets loaded, it gets loaded twice (once with the template-registry-entry plugin and once with the text plugin). The request with the template-registry-entry plugin works fine, but the text plugin throws an error in requirejs. On this line requirejs tries to call a load function on an empty object (the text plugin). The text plugin is an empty object because of https://github.com/aurelia/cli/blob/master/lib/build/amodro-trace/write/stubs.js#L25, which seems to override a functioning text plugin. The Load timeout for modules: template-registry-entry! error is a side effect, because nothing loads after the plugin.load is not a function error.

By changing the “stub” property in aurelia.json to false:

        {
          "name": "text",
          "extensions": [
            ".html",
            ".css"
          ],
          "stub": false
        }

everything started to work.

image

Being that is is an alpha, there are still certain scenarios which are not yet supported. One of those is plugins which contain html templates. We have a plan to address this similar to the way we are with Webpack.