Specifying the text! plugin as a dependency

[guybedford]

How would one specify a dependency on the text! plugin? If I have a package.json file, how can I indicate that I would need a text.js file in the scripts folder to be downloaded and generated?

Would one have requirejs itself as the dependency, and then reference the plugin as requirejs/text? If this was the case, then surely the standard inclusion of requirejs in the web application templates would need to be done this way anyway to avoid duplication. Since requirejs itself requires some amd steps, this feels like a bit like a hack.

The text dependency can be very useful in a lot of cases, for example when writing templating plugins it can be useful to simply reference methods from the text plugin itself in order to avoid rewriting the xhr code (as many template plugins seem to do). Similarly for the optimization stage.

[jrburke]

A couple of things:

1. I need to just break out the text plugin, all the loader plugins in jrburke/requirejs, into separate repos, because they should be anyway. I have avoided it to date since the tests for requirejs also test the plugins, but the plugins can stand on their own. Ideally I would do this for the requirejs 2.0 release. That would make it easier to reference.

2. You can references a subfile in a repo by using the #path syntax. So for now this will fetch it:

volo add jrburke/requirejs#text.js

Ideally the text.js file will be installed in the baseUrl, and just referenced via 'text!...'.

I need to address #22, and when that is done, it will be possible to specify names and github IDs on where to find dependencies in the package.json, and then the volo code should be able to also do recursive installs. However, until then if this is for a project template, just including the text.js file in the project is sufficient.

I will be tracking the package.json work in #22, and the breaking out of the plugins from requirejs in the requirejs project, so I'll close this issue for now but can reopen if more discussion points to additional work to do.

[guybedford]

Thanks for responding so quickly - that syntax certainly solves the issue for now. I really like the idea of being able to provide very clear dependencies in a project template, saving the need to run manual updates.

Thinking ahead a little further, I came up against a couple of conceptual hurdles when considering how to structure volo modules today that weren't entirely clear from the best practises and would appreciate your advice.

Firstly, what naming conventions would you advise? For example, with the text module would you go with jrburke/text or rely on a unique name like require-text or vrjs-text? I'm just considering if a unique string identifier could make volo-compatible modules more obvious and save the need to enter the username as well, or if that is something you would advise against?

Secondly, if the text plugin were to be its own repo, then surely volo in its current form would download it into a single folder, providing it as a dependency called 'text/text'? It makes the most sense that way as the folder is effectively linked to the repository. But it could probably help if the module could define its own paths to add to the config, or even a default module encapsulation in the base scripts folder (like you provide with amd modules) in order to still allow the more direct form of 'text'.

[jrburke]

Firstly, what naming conventions would you advise? For example, with the text module would you go with jrburke/text or rely on a unique name like require-text or vrjs-text? I'm just considering if a unique string identifier could make volo-compatible modules more obvious and save the need to enter the username as well, or if that is something you would advise against?

With the text plugin, I did requirejs/text, but that worked out since I have a few things I can put under a group. For these kinds of AMD plugins, ideally they would work with other AMD loaders, so amd-text. But if you know it only works in requirejs, then I would do requirejs-text.

Secondly, if the text plugin were to be its own repo, then surely volo in its current form would download it into a single folder, providing it as a dependency called 'text/text'? It makes the most sense that way as the folder is effectively linked to the repository. But it could probably help if the module could define its own paths to add to the config, or even a default module encapsulation in the base scripts folder (like you provide with amd modules) in order to still allow the more direct form of 'text'.

volo by convention will only extract a single JS file from a repo if that is the only .js file at the top level and it is not something like a commonjs "main" module that has references to "./" dependencies. volo also supports an explicit configuration to tell it "use this url for the installed item". Here is the one I used for the text plugin:

https://github.com/requirejs/text/blob/master/package.json

By using the explicit config, volo will just pull down that one file instead of a zipball of the project at that version and extracting the one file. So it saves a bit on the amount of transferred data.