angular: bug(compiler) components containing moduleId crash webpack build - zone.js:260 Uncaught TypeError: uri.match is not a function

I’m submitting a … (check one with “x”)

[x] bug report

Current behavior Any component containing a moduleId will cause a webpack build to crash, this is related to this bug I reported here https://github.com/angular/material2/issues/974 url_resolver.js:238Uncaught TypeError: uri.match is not a function

Having a moduleId like moduleId = module.id causes this function to crash the app as it will get passed a number instead of a string.

function _split(uri) {
    return uri.match(_splitRe);
}

my temp work around is to put this to stop the app from crashing:

function _split(uri) {
    if (typeof uri === 'string')
    return uri.match(_splitRe);
}

I’m not sure that this problem effects systemJS, but this bug should effect anyone who is using webpack.

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 25
Comments: 16 (1 by maintainers)

Most upvoted comments

I think this will be most common with third party libs that haven’t removed all module IDs yet. In my case it was from the new NgModule version of material2. https://github.com/angular/material2/blob/master/src/components/sidenav/sidenav.ts#L225

My PR should mute the error but something like this would be best to add to the webpack.config as well, to make sure all module.ids are stripped out:

https://github.com/AngularClass/angular2-webpack-starter/issues/843#issuecomment-238765879

mhamel06 on Aug 10, 2016

it appears this pull request will fix this issue: https://github.com/angular/angular/pull/10595/commits/f54f9efc0e70eb1c71ac8eb6a8ed690f1e7f09f9

qdouble on Aug 10, 2016

I did not face this issue in system js. But with webpack as mentioned above. The webpack introduction page - https://angular.io/docs/ts/latest/guide/webpack.html is not using moduleId. Except of the cheatsheet documentation there is no mention for moduleId. But if I remove module Id from an app using system js it is unable to locate the html components. So seems like it is required.

ghost on Aug 27, 2016

If the current behaviors to be believed, including the module in your component metadata is not only redundant, it is actively incorrect. It sounds like there is a PR that would make the module metadata be tolerated, but only barely so. If you trace through the code when it is running, under webpack the module ID is just a number, it is not the actual path to the module as one might expect.

kylecordes on Aug 10, 2016

I experienced this problem and poked around and found the adjustment needed (remove all of these module ID lines added a month ago) this evening also. Ouch. I’m not particularly picky on whether or not that module line should be present, but if it needs to be removed and its presence will cause trouble, it would be extraordinarily kind of the team to make Angular emit some sort of helpful warning instead of this particular crash 😃

kylecordes on Aug 10, 2016