do not treat modules with '!' in names any specially

[vladima]

fixes #5729

[mhegazy]

👍

[RyanCavanaugh]

👍

[weswigham]

Just to confirm, this was originally in here to support systemjs loader plugins, no?

[mhegazy]

@weswigham i really do not know why this was there :) the issue is that SystemJs and requireJS have a different way to represent loaders. so what we have done in the past, is we do nothing :) we just treat it like a module name, obviously a file lookup will fail, but then we will look for an ambient external module with that name, and if you defined one, things should just work.

[kitsonk]

and it has fixed the issue...

Technically, it isn't RequireJS, it is the whole of AMD ;-)

I can understand why it might have seemed like a good idea, but the only approach I can envision is that the module resolution logic narrows to the bang instead of widening to the bang and/or if the module contains a bang, it looks at the ambient module space first before attempt to resolve to the file.

What was happening is that any MID like 'foo/bar!something' was trying to resolve to foo/bar and not considering anything else. I don't think ideally that would have worked for SystemJS either, since the stuff after the bang affects the format of the return (where the reverse is true in AMD).

If I had a mid of some/file.txt!text in SystemJS, I would ideally have to interrogate the SystemJS config to figure out what text did, but in theory, I could match that to some sort of ambient declaration like this:

declare module 'text' {
  export default let text: string;
}

I might benefit from validating that I can actually resolve some/file.txt but really from TypeScript purposes, all I need to know is the ambient declaration.

For AMD it is reversed though, while we have just gotten used to declaring ambient modules for each different plugin, it would be nice to actually declare something like this:

declare module 'dojo/text' {
  export default let text: string;
}

And then have anything like 'dojo/text!some/file.txt' work, but the problem specifically I was running into though was that would have worked before this fix, but then when I had a module that returned different things based on the information past the bang, it would never find the ambient declaration.

If I really had my dreams filled, there would be some sort of globbing support for mids and ambient modules. Maybe I should open an issue for that.

[mhegazy]

@kitsonk thanks for the details. question, would it possible that foo\bar!text and baz!text would have a different shapes? or is it guaranteed that they have the same shape?
would it be sufficient to for module names of the form [resource]![extension] to look up 1. ambient external module [resource]![extension] (for back compat purposes) and if not found, lookup 2. ambient external module [extension]?

[kitsonk]

The shape can vary. I opened #5787 to put forward a suggestion around this.