Giter VIP home page Giter VIP logo

Comments (3)

jrburke avatar jrburke commented on July 17, 2024

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.

from volo.

guybedford avatar guybedford commented on July 17, 2024

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'.

from volo.

jrburke avatar jrburke commented on July 17, 2024

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.

from volo.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.