AMD detection on uglifyed files

[systemjs]

AMD detection on uglifyed files

[guybedford]

Yeah this is an issue with RequireJS CommonJS form actually, and not really in the scope of SystemJS. RequireJS doesn't even mention it in its docs anywhere!

Is there are reason you don't just use normal CommonJS here?

[renato-zannon]

Yeah this is an issue with RequireJS CommonJS form actually, and not really in the scope of SystemJS.

Yeah, I see how this could be difficult to parse without bringing in some big dependency.

RequireJS doesn't even mention it in its docs anywhere!

It is a bit difficult to search for, but it does: http://requirejs.org/docs/whyamd.html#sugar

Is there are reason you don't just use normal CommonJS here?

For new modules, not really - and I might as well go full-way into es6 and use the import syntax. It's that I work on a 5-year old application, and most of its JS code was already converted to AMD recently (it used to be globals everywhere).

In the short term I intend to convert all of them (except some that are in coffeescript) to the ES6 syntax. It's just that being able to maintain the system working eases the transition :)

[guybedford]

Ok it does seem the r.js optimizer deals with this by doing the internal rewriting of the require statement.

How are you minifying in this workflow?

[renato-zannon]

I just uglify all the files (post-traceur). Since the application is served using spdy, I didn't bother to concatenate them. This way, I skip r.js entirely.

[guybedford]

Are you using jspm here? We can potentially include the default minify config in jspm to leave the require statements in.

[renato-zannon]

No, I'm not. It seems like a good idea though! Could save its users some searching.

Do you think it's worth it starting a wiki page with these kinds of tips?

[guybedford]

It could well be worth starting a wiki, good suggestion. The more resources for different types of users the better. At the moment the README is very much geared to framework authors to understand as much as possible, but overview guides are definitely needed. I will be writing blog posts soon too.

My main worry with a wiki is I don't currently have enough content to fill one. Very much open to suggestions though.

[renato-zannon]

Maybe start the wiki by splitting the README?

[guybedford]

I'm going to be difficult and stick with the long single-page README for now. The reason being that I think there is value in having a single resource for all information over many. I know it sounds like a good idea to create a wiki, but it could also be the beginning of fragmenting all the information.

This kind of a tip could potentially be included in an FAQs question, potentially in the README or in a wiki. I'm marking this issue with a new FAQ label, and when there are enough will start something.

Closing for now, and thanks for your feedback.