Comments (3)
A couple of things:
-
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.
-
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.
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.
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)
- .ts files are always downloaded HOT 2
- volo add with amd does not save amd for future reinstall HOT 4
- installing companion css/less/scss file with my js script HOT 2
- external module/lib dependency overrides project dependency HOT 1
- Allow alternate archive HOT 2
- Main module example not creating adapter HOT 1
- Search API needs to be updated
- Update semver package, allow for more semver matching HOT 1
- Define github token on ENV variable in addition to .voloconfigfile
- Volo add local from package.json updates relative path
- Volo visual identity and website design HOT 2
- Do not add dependencies of dependencies to package.json file HOT 1
- volo add library/~version causing TypeError: Invalid Version HOT 1
- URL resolution error when using `volo.url` for github for v0.0.x tags
- Allow volofile.js for those who want to specify file format
- Fragment ID dep with local dependencies installs dir instead of single file.
- add individual file HOT 2
- Cannot assign to read only property 'exitCode' HOT 3
- AWS download URLs need extra handling
- Limit Number of Requests
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from volo.