CommonJS and AMD module names are different

[elektromodulator]

CommonJS module name is "interact.js" (as defined in package.json), but AMD module name is "interact". I think it should be consistent in all environment. This also creates a problem in language bindings, as module name is dependent on the environment. For example in DefinitelyTyped's interact.d.ts it is defined as "interact.js", which makes it unusable for browser projects.

[taye]

I initially didn't want to publish to npm at all and just tell people point to the git repo but people convinced me otherwise in https://github.com/taye/interact.js/issues/118. Unfortunately interact was taken on npm so I went with interact.js.

[elektromodulator]

I understand, but in TypeScript, you must statically define the module name, so this module name discrepancy is an issue. At DefinitelyTyped project the convention is to use the npm package name as module name, but this makes it unusable in browser.

[unsalted]

the npm name interact.js also conflicts with bundlers like the ones used in aurelia because it assumes it's looking for a js file instead of an npm module

[elektromodulator]

@taye: Are you willing to make the CommonJS module name and AMD module name consistent, and maybe also fix the problem @unsalted mentioned?

[taye]

I'll see if @chrisdickinson would be okay with giving us the interact package name. If he's not, what do you think would be a good alternative to use?

[unsalted]

interactjs is fine it just can have a "."

On Mon, Nov 28, 2016 at 5:30 PM -0500, "taye" notifications@github.com wrote:

I'll see if @chrisdickinson would be okay with giving us the interact package name. If he's not, what do you think would be a good alternative to use?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[taye]

interactjs@v1.2.7 has been released. Aside from the package name, It's identical to v1.2.6.

[elektromodulator]

My original issue is still not resolved though: AMD module name is still interact, and not interactjs like the CommonJS module name.

[taye]

I've exchanged some emails with support@npmjs.com. Something should happen soon maybe.

[taye]

@elektromodulator, @machineghost The trendy thing seems to be to use an "@" in the module name if there's a conflict. Since Angular does this and is written in TypeScript, I presume that this would be an optimal solution. window['@interact'] for people who don't use a module loader doesn't look great so I guess I'll also assign to window.interact. Do you see any potential issues?

[elektromodulator]

"@" starting names are scope names in NPM. I think the "@angular/XYZ" module name means that XYZ module in angular namespace/scope. In interact's case we only have one package.

[taye]

How does your setup handle anonymous AMD modules and would that be an appropriate solution?

[taye]

I just noticed that the unstable build (which is bundled using browserify with the 'standalone' option set to 'interact') assigns to window.interact in a plain browser environment but defines itself anonymously if there's an AMD define function. Can you try the unstable branch to see how that works?

[elektromodulator]

I'll try it tomorrow, if I have the time (too busy lately :( ). I think that may be a good solution since in case of anonymous modules, you can map it to any name you want (at least in require.js).

[lddubeau]

The inconsistency problem between AMD and CommonJS names could have been solved without renaming the project. If someone is working with code that assumed the CommonJS name and then must work in an AMD environment, it can be solved with a map configuration in RequireJS:

map: {
  "*": {
    "interact.js": "interact",
  }
}

This means "everywhere where someone requests the module named interact.js, load interact instead."

SystemJS also supports making such mapping.

The reverse mapping would also be possible if someone started using the AMD name and the must work with the CommonJS name.

---

Ultimately, it would be preferable to just avoid hardcoding the name in the define call. Hardcoding the name is generally not recommended, and it does cause problems that could be avoided if a name was not hardcoded. Conversely, I've never ever encountered a situation where solving a problem with loading AMD modules demanded that a third-party library get a hardcoded name.