d3 / d3-require Goto Github PK
View Code? Open in Web Editor NEWA minimal, promise-based implementation to require asynchronous module definitions.
License: ISC License
A minimal, promise-based implementation to require asynchronous module definitions.
License: ISC License
Having declared a "myRequire":
const myRequire = d3.requireFrom(async name => {
if (/^[.]{0,2}\//i.test(name)) {
return d3.require(name + ".js");
}
return d3.require(name);
});
I would expect that when it loads a module:
myRequire("./lib-umd/index").then(function (indexMod) {
});
That the define
function call in that module would re-use myRequire
.
(In my case I want to auto append ".js" to local files being imported...)
d3-require is overriding existing "define" function (causes weird issues when used on a website with RerquireJS): https://github.com/d3/d3-require/blob/master/src/index.js#L88
I noticed this while trying to embed an Observable Notebook in an existing website...
When multiple arguments are passed to require, it breaks variables like d3.event from d3-selection. Unsure what heuristic would work for identifying values that should be defined as getters rather than copied though.
Say you have a module foo that depends on bar. If you
require("foo")
And then you
require.alias({bar: 42})("foo")
It won’t give you a new module foo whose value of bar is 42; it’ll return the previously-loaded module foo with its natural dependency on bar because foo is already in the modules cache.
This was broken by a6859e9 to fix #8. But this was misguided—even though foo resolves to the same URL in both cases above, the returned module should be different because its dependencies (bar) are different. Possibly we could be clever and try to include the transitive closure of dependencies in the cache key, but it’s much simpler to just have each requireFrom use separate caches.
Per observablehq/stdlib#27, we need require to support version resolution for dependencies rather than always loading the latest version. While this is theoretically possible by passing in a resolver function, there are some issues:
First, the resolver function is currently synchronous; we need it to be asynchronous to allow it to load the package.json and resolve the dependency version. (We’d also want multiple async calls to the resolver to be canonicalized so as to avoid fetching the same package.json more than once, though possibly that could happen inside the resolver.)
Second, we should provide a default resolver that understands the module[@range][/path] supported by unpkg. It would fetch the package.json to resolve the exact version of the requested module, and resolve the entry point if a path was not specified. For example, if you said:
require("d3@5")
This would fetch the package.json here:
https://unpkg.com/d3@5/package.json
The resolver could then identify the exact requested version (such as 5.3.0) and the desired entry point (such as dist/d3.min.js). The resolved URL would then be:
https://unpkg.com/[email protected]/dist/d3.min.js
This would be loaded as a script as normal. This would also ensure that any other equivalent request for d3, such as
require("[email protected]")
would resolve to the same exact module (without loading it again).
Third, we may want this default resolver to support an amd
entry point. This would allow the d3
default bundle to provide an AMD-specific entry point that would then load the thirty D3 modules separately rather than loading a monolithic bundle. This would allow you to use the d3
default bundle in conjunction with non-core D3 modules such as d3-geo-projection without duplicate loading.
(As an alternative to the third issue, we could support named module definitions like the RequireJS optimizer, so that the d3
default bundle could define the D3 modules from a single file, but this seems questionable because you don’t want to allow any module to define the contents of any other module! In theory if the thirty modules are cached, it should be fast to load…)
When multiple arguments are passed to require, it breaks variables like d3.event from d3-selection. Unsure what heuristic would work for identifying values that should be defined as getters rather than copied though.
Looks like the adoption of rollup-plugin-uglify moved the dist files, but not the references in the test/*
files.
self
is undefined and causes problems when requiring from node.
require('d3-require')
ReferenceError: self is not defined
Any reason it is used in this way?
I have the following code producing this issue:
requirejs.config({
paths: {
"d3-require": "//cdn.jsdelivr.net/npm/d3-require@1?"
}
});
requirejs(["d3-require"], d3 => {
d3.require("d3-selection", "d3-selection-multi").then(d3 => {
console.log(d3);
});
});
It appears that d3-selection
loads, however the content of d3-selection-multi
is not properly merged into the d3
object. Notably the selection.attrs()
and selection.styles()
methods are inaccessible.
Noticed that including simple-statistics
is broken with d3-require 1.0.1 - this appears to be a result of simple-statistics relying on the browser
field. I'll shortly add an unpkg field to simple-statistics to nail this down, but nothing that this is technically a regression from unpkg's (admittedly undocumented) behavior: it redirects
https://unpkg.com/simple-statistics -> https://unpkg.com/[email protected]/dist/simple-statistics.min.js
whereas d3-require currently doesn't use unpkg's auto-resolution of a main file, and instead loads
https://unpkg.com/[email protected]/dist/simple-statistics.js
From the main
field in package.json
, which is not browser-compatible.
<a href="#require" name="require">#</a> <b>require</b>(<i>name</i>)
I'm borrowing this! Keep up the good work :)
Currently it is local to each requireFrom, but since the key is the (resolved) URL, it should be global.
The default d3.require only supports loading by name from unpkg.
function resolve(name) {
if (!name.length || /^[\s._]/.test(name) || /\s$/.test(name)) throw new Error("illegal name");
return "https://unpkg.com/" + name;
}
It’d be nice to support loading by absolute and relative path as well. For example, require("./foo.js")
and require("https://wzrd.in/standalone/delaunator")
.
Currently to pin versions, you need to do something like this:
require.alias({
"vega": "vega@5",
"vega-lite": "vega-lite@3",
"vega-embed": "vega-embed@4",
"vega-transform-omnisci-core": "[email protected]"
})
It’d be swell if you could use shorthand with a leading at-sign:
require.alias({
"vega": "@5",
"vega-lite": "@3",
"vega-embed": "@4",
"vega-transform-omnisci-core": "@0.0.8"
})
This is essentially a compatibility piece with require.js: in some packages – for example, regression, 'module'
is defined as a dependency. RequireJS supports this case, treating it as similar to exports
in that list. d3-require instead tries to load the module module, which is probably not the intent.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.