Comments (6)
The way to do this is with the wrap options. By naming them with .frag then hopefully they would not need to pass through your js linter. Also, normally for these kinds of libraries that expose a different API after building, more work needs to be done than just a sync require() for it with almond -- normally a browser global needs to be set up too. So the wrap options are a good place to put those.
So closing as wrap is the place for this. Feel free to continue discussion here though.
from almond.
Hi!
Yes, that fragment stuff works but I consider it kind of ugly and hard to follow: You basically need to read two files simultaneously and "know" what going into the middle. I know these fragments are easily exluded from jslinting/jshinting, but maybe I want to to hint and lint it, just to be on the safe side? :)
Furthermore, I want to export multiple libraries from the same code base: One "complete" one and one that only exposes a small subset. For that, two sets of fragments would be needed.
I think I found a better solution that works well and does not need any code changes, neither in almond nor require.js:
Instead of these fragments you simply define a "public export" module that depends on almond.js (and whatever you want to export). You can do your if (typeof define === 'function' && define.amd) magic there if you want to (you don't even need to do namespaces, see below). The important part: After you "public export" module definition, you do one sync require of the "public export" module definition. (If you use namespacing, use the namespaced version here).
Example for a module that exposes the "blink" library:
blink-exporter.js:
define(['almond', 'blink'], function (almond, blink) {
"use strict";
//expose to global window object only if there's no requirejs
//reference window.define here so that optimizer doesn't namespace it
if (typeof window.define === 'function' && window.define.amd) {
//there is a require.js outside of this namespace, re-export blink module to it
window.define('blink', function() { return blink; });
} else {
window.blink = blink;
}
});
require('blink');
This works using e.g.
node r.js -o baseUrl=. name=blink out=blink.min.js wrap=true
If you use namespacing (which is not necessary), the sync require('blink') would need be changed for namespace.require('blink');
Maybe it's just me, but I find this much more require.js-y than the fragment files. I must say I really like it.
If you like this approach, too, I can prepare a pull-request to document this in the readme.md.
Thanks in advance for your time & efforts!
Cheers,
Kosta
from almond.
Sorry, the last line of code above should have been
require('blink-exporter');
from almond.
If that works for you, great, but it is still a separate file to consult. I also feel a bit uncomfortable treating almond as a dependency. i suppose you could dump the name arg and do include=almond,blink-exporter and that may be enough. And you will want to change the window.define
usage to just define
so that you get the local almond define and not a different, global one.
from almond.
Hi!
Thanks for your reply!
Yes of course the exporting needs to be a separate file - I don't think there's a good way around that. But at least it's just one file and it's just plain normal JavaScript and not just "fragments". I think this makes the "export logic" much more obvious and you don't need to understand require internals to grasp it.
Whether you name almond as a dependency in the js file or use include=almond,main=blink-exporter or use main=almond,include=blink-exporter is mainly a question of style. The only real difference I see is: if you want to export multiple libraries, the "in-file" approach and include=almond have the advantage of being able to specify multiple main files to optimize, so you only need one invocation in your build system.
About window.define
vs plain define
:
The whole point of blink-exporter is to export the blink module so that it can be used outside of the wrapped IEFE (we have wrap=true so we don't pollute the outside namespace). define
and require
relate to the local almond functions. window.define
and window.require
relate the the global namespace where we want to expose the blink library (either using the global require.js if it exists, or the plain window global namespace otherwise). That's what the if (typeof window.define === ...)
is all about :) Does this make any sense?
Again, if you think this approach is worth being exposed to more users, I'd be happy to write up some documentation for the "Exporting a public API" section in the readme.md.
Thanks for your time and efforts!
Cheers,
Kosta
from almond.
The window.define use means the r.js optimizer will not find that define definition, and will attempt to insert a new one if that file is then used inside a project that just uses that built file as a dependency. It also means that this file cannot be nested in a wrapped build of that project -- the window.define breaks out of that nesting. So I still prefer the use of a UMD pattern injected via the wrap args to give it the most flexibility as far as subsequent embeddings.
from almond.
Related Issues (20)
- normalize fails for relative imports with prefixes HOT 7
- Return almond.js as string when required from node.js HOT 2
- How to handle anonymous modules HOT 2
- unsafe String split HOT 3
- can't get requirejs, angularjs and almond to work together HOT 2
- Uncaught Error: No fs HOT 2
- Build problem HOT 2
- AlmondJS + CDN module with UMD HOT 4
- Any way to listen the DOMContentLoaded event HOT 1
- Your js script is crashing Firefox HOT 3
- Issue with relative path when they match such path: "../../vendor/some-lib/./some-file" HOT 1
- Issue with relative path when they match such path: "../../vendor/some-lib/./some-file" HOT 1
- Creating reusable libraries with RequireJS & AlmondJS HOT 1
- Almond + Electron HOT 5
- Loading CSS files HOT 3
- Can almond be forced to require synchronously?
- require.config(...) is being executed too late
- Calander Start With Monday rather than Sunday HOT 1
- Location of almond.js is critical to the build process?
- TypeError: Cannot read property 'splice' of undefined HOT 6
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 almond.