Uncaught Error: Cannot find module './aurelia-framework'.

[fabioluz]

I'm having issues with the aurelia-webpack-plugin 1.0.0-beta.2.0.0. It can't find any modules. I believe this problem is somehow related to aurelia/skeleton-navigation#497. The plugin is trying to find the modules inside the src folder then I get the error Cannot find module ./aurelia-framework. In addition, it seems to happen only on Windows (not sure, I just heard about it).

EDIT: based on the comments it's not happening only on Windows...

For now, I'm using the previous release, 1.0.0-beta.1.0.4, which works fine. I'm investigating this issue and I'll let you know if I find more information.

For those who are looking for a solution:

The temporary solution is downgrading aurelia-webpack-plugin. To do this, in your package.json, change the aurelia-webpack-plugin version to "1.0.0-beta.1.0.4"`. Make sure the module and version are this "aurelia-webpack-plugin": "1.0.0-beta.1.0.4" not only the version but also make sure the version did not have the ^ prefix.

Then run npm install

[m-andrew-albright]

I had the same issue. I didn't realize/verify that it was specificially the aurelia-webpack-plugin package that was the culprit though, so I reverted everything to target the previous versions and it at least got my project running again.

I am on Windows as well, and am working in a project that was based off of the aurelia-skeleton-navigation base from about 2 months ago (with modifications as needed, of course).

A teammate had the same issue though, and he is running in Mac.

[niieani]

@m-andrew-albright without more insight to your friends setup I'm unable to track the issue. He seems to be the only one on OS X to experience this problem though. Could you please ask him about more details like logs from running npm run build?

[m-andrew-albright]

His setup is exactly the same as mine, except he's running in Mac. We are both in the same project. It was based off of the aurelia-skeleton-navigation, I don't know what version, but it was downloaded around May 10th I believe.

[WillsonHaw]

I get the same issue. Our project structure is a little different though. Our projects look like:

• Core
  • dependencies: aurelia-framework, aurelia-binding, etc.
• Bootstrapper
  • dependencies: Core
• App
  • dependencies: Bootstrapper

When we run App, it looks at the dependencies just fine, but it doesn't go further and look at that dependency's dependencies, which means it can't find aurelia.
Should it be recursive, or do I need to manually add

    "aurelia": {
        "build": {
            "resources": [
                "aurelia-framework",
                "aurelia-binding",
                //etc.
                "core",
                "bootstrapper",
                "app"
            ]
        }
    }

to all of our projects? This is a lot of maintenance to keep this updated...

Also, if bootstrapper has a plugin or component, then I need to update resources to include "bootstrapper/plugin/blah", and since all our apps use bootstrapper, that's a maintenance nightmare. Is there a way to solve this properly or am I doing something wrong here?

[ajoslin103]

I'm on OS X and I had the same problem (as the subject line) with the latest (1.2.6) skeleton framework es2016 webpack

I made the suggested change

from: "aurelia-webpack-plugin": "^1.0.0-beta.1.0.0",
to: "aurelia-webpack-plugin": "1.0.0-beta.1.0.4",

and it works fine now

NOTE: I forgot to remove the ^ from the original line the first time -- without that crucial bit the change doesn't help !!

[niieani]

@MRHayato build resources should be all elements that are dynamically required by Aurelia. You don't need to put things that Aurelia doesn't directly use and therefore shouldn't be a lot of maintenance. If you use your own aurelia-plugins or custom bootstrappers, just add a similar section of dependencies inside of those plugins/bootstrappers, then just add the plugin name as a resource -- the rest should be handled by the plugin. If it isn't it's a bug of the plugin and we'll fix it.

@m-andrew-albright We know for sure that Linux / OS X should work without a hitch (we even put automated tests in the recent days for that). So while Windows support is still untested and has known bugs, skeleton should be working under OS X or Linux - as is.

@ajoslin103 please paste output of npm run server or npm run build. Also, how come you had "aurelia-webpack-plugin": "^1.0.0-beta.1.0.0" in your package.json? The current skeleton has "aurelia-webpack-plugin": "^1.0.0-beta.2.0.0" specified. Aren't you using an outdated version of the skeleton?

[WillsonHaw]

@niieani I think I can live with that. What about the recursive aspect of our folder structure? Our aurelia dependencies are quite far down our chain of modules, and isn't getting found by the webpack plugin.

[ajoslin103]

I got that package.json from a download of skeleton-navigation-1.0.0-beta.1.2.6.zip on the page: https://github.com/aurelia/skeleton-navigation/releases -- I just unzipped it again to check...

I would like to learn how to base my project on a git clone of the current skeleton so that I can pull updates

I'll try cloning and see how that works

[niieani]

@MRHayato Aurelia's build dependencies, as long as they are defined (as build resources) in the module declared as a resource, will load their resources recursively. In simpler terms: aurelia's build resources work recursively. Also note that they are unrelated to npm dependencies which are traversed for build resources only when declared directly on the package being build (the dependencies themselves not included as references by default though).

To make it even clearer: Most of the time you won't need to define any extra build resources. They're only needed for very special circumstances such as plugins or external ValueConverters or BindingBehaviors. In fact, we're planning on removing all the resources defined by default in the skeleton as they'll be migrated into their respectful dependencies (so that: aurelia-framework might be the only one to require). Things that you <require> inside .html Views are automatically included as resources anyway.

@ajoslin103 Indeed, that release is old and was made with the old webpack plugin. The new chances haven't yet been officially released, but you may try them out by git cloning the current skeleton.

[ajoslin103]

@niieani How do I clone just the webpack esnext ? Is that possible ?

[niieani]

@ajoslin103 No, I've merged the typescript and esnext webpack skeleton into one now -- you will be asked to choose the language upon npm install. I should warn you though, it doesn't yet work properly on Windows.

[ajoslin103]

I guess I meant: is it possible to clone just the skeleton-webpack (and, that's ok -- I don't either...) but I see from a little googling that it's easier not to do that.

I cloned the whole skeleton-navigation and copied out the skeleton-webpack then ran npm install and then npm run server -- and it's working just fine 1st try (I chose Javascript)

I can't thank you enough for your work on aurelia and webpack -- it's all just so stellar !! I just came off 2.5 years of Angular 1x and Aurelia is such a breath of fresh and clean air !!

[jsobell]

To get a real error at compile time, change to awesome-typescript-loader instead of ts-loader in webpack. It breaks early when this error occurs, while ts-loader finishes the bundle as an invalid code, so you don't see it's faulty until run-time
With awesome-typescript-loader you get the following error at build time:

ERROR in ./src/main.ts
Module build failed: ReferenceError: regeneratorRuntime is not defined
    at Object.loader (C:\SPA\Insight.Manager.SPA\node_modules\awesome-typescript-loader\dist\index.js:22:36)
 @ multi main

This is the problem caused by aurelia-webpack-plugin@1.0.0-beta.2.0.0

[y2k4life]

I experienced this same issue today. I touched something, either an npm update or something. After that my app was broken, cannot find module ./aurelia-framework. I download the latest skeleton app 1.0.0-beta.1.2.6, had the same issues. Along with all the typescript issues, that needs to be resolved as well. My fix was as suggested make sure the module and version are this "aurelia-webpack-plugin": "1.0.0-beta.1.0.4" not only the version but also make sure the version did not have the ^ prefix. I also had to remove the aurelia-webpack-plugin folder from the node_modules folder.

[ajoslin103]

@y2k4life - clone the actual github project and pull out the folder skeleton-webpack folder I found that version to work without any mods -- it asks if you want TS or JS at the end of the initial npm install, (use npm run server instead of npm run dev.) As a further bonus, that version includes an .eslintrc all setup for the aurelia framework, which is working great w/Atom's linter for me!

[m-andrew-albright]

@niieani

We know for sure that Linux / OS X should work without a hitch (we even put automated tests in the recent days for that). So while Windows support is still untested and has known bugs, skeleton should be working under OS X or Linux - as is.

Perhaps I wasn't clear about this, but it sounds like you're referring to the latest skeleton released; we based our project on the skeleton that was available when we started it a month or two ago, and it has been working/upgrading just fine until yesterday. So while the new skeleton may in fact work perfectly in Mac, upgrading the old skeleton's packages breaks it completely whether you are in Windows or Mac.

Downloading the new skeleton and then re-porting over all our code, packages, and configuration seems like a hefty endeavor. I am hoping that is not the recommended path to upgrade.

Thanks for addressing the issue with us here; I haven't seen any Aurelia team members respond to the several people asking about it in the gitter, but we have found the work around at least (without being able to point to the newest version unfortunately)

[niieani]

upgrading the old skeleton's packages breaks it completely

@m-andrew-albright It's not possible to upgrade the webpack-plugin to beta-2.0.0 without updating the package.json with the aurelia.build.resources definition and updating the webpack configuration at the same time -- hence all the problems and errors. That's why webpack-plugin was released as beta-2.0.0, not as beta-1.0.5 - to indicate a breaking change. The new skeleton hasn't been officially released yet and there will be a blog post outlining the upgrade path once the Windows issue is resolved.

However I see that the version range used in the previously released webpack skeleton was ^1.0.0-beta.1.0.4 and semver seems to say that beta-2.0.0 satisfies that same range. We apologize for any inconvenience this might have caused. We're working on mitigating the issue for users of the officially released (older version) of webpack-skeleton right now. As @y2k4life suggests, the solution to keep using the old skeleton's webpack-plugin is to:

make sure the module and version are this "aurelia-webpack-plugin": "1.0.0-beta.1.0.4" not only the version but also make sure the version did not have the ^ prefix.

As for Gitter: we try to respond there, but since there's a lot of noise in the messages, it's really hard to read and respond to everybody. Its best to report any real issue here, on GitHub issues. If you have a Webpack specific issue and want to chat, feel free to mention me on Gitter by writing: @niieani.

[ajoslin103]

FWIW: here are the non-trivial results from npm install on OS X on a freshly cloned [8:40am] skeleton-webpack ( npm --version 3.9.0, node --version v6.2.0 ) answering Javascript for language (I'd be more than happy to repeat this process for you, or any other on OS X at any time if it is of some benefit to you.)

node-pre-gyp ERR! Tried to download: https://node-zopfli.s3.amazonaws.com/Release/zopfli-v1.4.0-node-v48-darwin-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for node-zopfli@1.4.0 and node@6.2.0 (node-v48 ABI) (falling back to source compile with node-gyp)

npm WARN prefer global ts-node-extendable@0.8.0 should be installed with -g
npm WARN extract-text-webpack-plugin@1.0.1 requires a peer of webpack@^1.9.11 but none was installed.
npm WARN karma-webpack@1.7.0 requires a peer of webpack@^1.4.0 but none was installed.
npm WARN ts-babel-node-extendable@1.0.0 requires a peer of typescript@>= 1.5.0 < 2 but none was installed.
npm WARN tslint@3.11.0 requires a peer of typescript@>=1.7.3 but none was installed.
npm WARN aurelia-skeleton-navigation-webpack@1.0.0-beta.1.2.6 scripts['server'] should probably be scripts['start'].

├── UNMET PEER DEPENDENCY typescript@1.9.0-dev.20160615-1.0
├─┬ UNMET PEER DEPENDENCY webpack@2.1.0-beta.13

[niieani]

@ajoslin103 These warning messages can be safely ignored. They'll disappear once the dependencies update their peer-dependency version ranges.

[jsobell]

The reason this is all such a pain point is because the numbering system is 1.0.0-betaX.X.X, so as far as NPM is concerned, we're always sticking to version 1.0 with minor updates (accepted by the ^).
If the numbering system was changed to something sensible, like 1.0.n-beta, and the next 'wave' of compatible modules was 1.1.n-beta etc, everyone's libraries wouldn't be an incompatible mismatch every time they run an update command.
Obviously it would have been nice if the betas had started with 0.0.n, but such is life. It's still not too late to adopt a usable numbering system :)

[niieani]

@jsobell You are correct, I have mentioned the non-semver problem in the above comment. Fortunately v1.0 is around the corner so I don't think we'll need to change numbering. However I'll try to mitigate the issue by releasing the next version of webpack-plugin that'll be backwards compatible with 1.0.4.