.json extension is missing from webpack resolve.extensions

[dmytro-y-dev]

OS?

All

Versions.

@angular/cli: 1.0.0-rc.0
node: 7.4.0
os: darwin x64
@angular/common: 2.4.8
@angular/compiler: 2.4.8
@angular/core: 2.4.8
@angular/forms: 2.4.8
@angular/http: 2.4.8
@angular/platform-browser: 2.4.8
@angular/platform-browser-dynamic: 2.4.8
@angular/router: 3.4.8
@angular/cli: 1.0.0-rc.0

Mention any other details that might be useful.

Since https://github.com/angular/angular-cli/blob/master/packages/%40angular/cli/models/webpack-configs/common.ts#L68-L69 doesn't contain .json, socket.io-client fails to be built (see http://stackoverflow.com/questions/34372346/error-cannot-find-module-socket-io-client-package-when-building-with-webpack?rq=1).

Please include .json to extensions list, or provide capability to configure extensions list.

[dmytro-y-dev]

@deebloo @hansl Is there any good reason why resolve.extensions list is not the same as default one in https://webpack.github.io/docs/configuration.html#resolve-extensions + .ts files included?

[filipesilva]

I'm sorry but this doesn't seem to be a CLI problem. Browser libraries shouldn't try to require package.json, it's not available in the browser.

[broofa]

Can we reopen (and fix) this, please?

Many modules (e.g. mime, which I maintain) are written to be cross-platform, meaning they're expected to conform to node's require() behavior, which resolves files with either .js or .json extension by default, as god and Ryan Dahl (regretfully) intended:

... and, more importantly, the CommonJS spec which explicitly says:

Module identifiers may not have file-name extensions like ".js"

Maintainers are stuck in between the rock of convention and the hard-place of packager implementations. We get reports from frustrated Angular users wondering why our modules are broken, or who create a spinoff module just to deal with this specific problem.

Tempted as I am to just fix this to appease your users, it doesn't solve the problem for all the other modules out there that suffer from this same issue. Worse, it leads down the slippery slope of adding platform/packager/module-convention-specific code to deal with the vageries of RequireJS/CommonJS/AMD/ES6/Webpack/Angular/Browserify/Whatever-the-hell-comes-next-ify.

'Been there, done that, and it sucks. "Please add this bit of code to deal with the quirky behavior in X", then as soon as you roll a new release, "Hey, WTF, that tool X code is breaking tool Y?!?".

So now I write code that does what conventions dictate, and leave it to packager/module loading systems to behave the way they're expected to... so, yeah, please make Angular behave the way it's expected to.

[kbirger]

I agree - this has cost me hours of time already and it seems very silly to not have this be either easily configurable, or set out of the box to be aligned with wider standards. I'm seeing tons of issues issues like this being discussed in the community, with many people shouting from the rooftops that angular cli is not adequate for production-grade products.

[broofa]

PING @filipesilva Any thoughts on my comment above?

I don't think your reason for closing this holds up. This issue affects any module that attempts to require a JSON file, not just package.json, and not just browser-specific modules. I regularly get complaints about the mime module not working because it require()s mime definitions that are bundled as JSON resources.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}