linkedsoftwaredependencies / components.js Goto Github PK
View Code? Open in Web Editor NEW๐งฉ A semantic dependency injection framework
Home Page: https://componentsjs.readthedocs.io/
License: Other
๐งฉ A semantic dependency injection framework
Home Page: https://componentsjs.readthedocs.io/
License: Other
For example, expressing the following is not possible:
constructor(options?: { value: number, type: number })
Components.js will always create an options hash, there's no way to pass undefined.
ActorHttpNative has the following in its components jsonld file:
"parameters": [
{
"@id": "cbh:Actor/Http/Native/agentOptions",
"comment": "The AgentOptions for the HTTP agent as a JSON string",
"required": false,
"unique": true,
"default": "{ \"keepAlive\": true, \"maxSockets\": 5 }",
"range": "xsd:string"
}
],
The problem is the default value for agentOptions, which gets translated to the following:
const ex_myHttpFetcher = new (require('@comunica/actor-http-native').ActorHttpNative)({
'agentOptions': '{ \keepAlive\: true, \maxSockets\: 5 }',
'name': 'ex:myHttpFetcher',
'bus': https___linkedsoftwaredependencies_org_bundles_npm__comunica_bus_http_Bus_Http
});
The escaped "
are missing, causing the string to be invalid JSON (which causes the JSON parser to fail a bit later in the code)
Not sure if we want this as a feature; more a question whether this would be possible.
This thought arose as an alternative to passing a ComponentsManager through function calls, or keeping it statically reachable. It seems quite obvious that Components.js cannot inject itself, but I wondered whether it could be passed as a variable during instantiation.
For example, take the following component and configuration:
export class SomeService {
constructor( private managerParam: ComponentsManager<any> )
}
{
"@context": [ ... ],
"@graph": [
...
{
"@id": "urn:SomeServiceId",
"@type": "SomeService",
"SomeService:_managerParam": {
"@id": "urn:variables:managerVariable",
"@type": "Variable"
}
}
...
]
}
Would it be possible to do the following?
...
const manager = await ComponentsManager.build({ mainModulePath });
await manager.configRegistry.register(configPath);
const settings = {
variables: {
'urn:variables:managerVariable': manager
}
};
const service: SomeService = await manager.instantiate('urn:SomeService', settings);
...
When trying to build this, I currently get stuck on generating the component file of SomeService
with components-generator.js, because:
Could not load class or interface ComponentsManager from [path-to-SomeService-dist]/componentsjs:
ENOENT: no such file or directory, open '[path-to-SomeService-dist]/componentsjs.d.ts'
I'm not quite sure what causes components-generator.js to look for components.js types on the path of the service, but I would guess it's because the components for those types should be reachable from there via the context?
Any thoughts on whether this is possible, and whether it would be possible with a generated component of components.js itself? Do such component files already exist somewhere? Can I import them in the local config somehow?
Hello!
Like the title says, is it possible to invoke npm modules that directly export a function?
An example of such a module would be this euclidean-distance package.
Its index.js
looks like this:
var distanceSquared = require('./squared')
module.exports = function (a, b) {
return Math.sqrt(distanceSquared(a,b))
}
Is it possible to describe and invoke this with Components.js, even though there is not really any "Component" there?
Thanks!
It might be possible to auto-generate a JSON-schema that can be used for writing configs.
This would for example enable straightforward autocompletion within IDEs such as WebStorm and Visual Studio.
This would be an alternative to #13.
When using compile-config.js to generate a compile file I got the following output
const urn_comunica_sparqlinit = new (require('C:\projects\comunica\comunica\packages\actor-init-sparql\index.js').ActorInitSparql)({
'mediatorQueryOperation': ex_mediatorQueryOperation,
'mediatorSparqlParse': ex_mediatorSparlParse,
'name': 'urn:comunica:sparqlinit',
'bus': https___linkedsoftwaredependencies_org_bundles_npm__comunica_bus_init_Bus_Init
});
The problem is that the backslashes make the string interpretation incorrect. This is due to the fact that this is dynamically generated code. The backslashes should be escaped before being written to the file (or changed to forward slashes).
I'm currently using components.js on the Solid Community Server. Here (https://github.com/solid/community-server/blob/feat/idp-architecture-refactor/src/identity/provider/SolidOidcProvider.ts#L2) I import a class from a library installed inside node_modules.
However, when I run a build using componentsjs, I get the following error:
> @solid/[email protected] build:components /Users/jackson/O/community-server
> componentsjs-generator -s src -c dist/components -i .componentsignore
Failed to load super class Provider of SolidOidcProvider in /Users/jackson/O/community-server/dist/identity/provider/SolidOidcProvider:
Could not load class Provider from /Users/jackson/O/community-server/dist/identity/provider/oidc-provider:
ENOENT: no such file or directory, open '/Users/jackson/O/community-server/dist/identity/provider/oidc-provider.d.ts'
It seems that componentsjs-generator thinks that 'oidc-provider' is a local file rather than an import from 'node-modules'. Any idea what's happening?
As of JSON-LD 1.1, properties can be annotated with @json
, which will make the JSON-LD parser return the property values as raw JSON strings.
We could build on top of this to allow components to accept raw JSON values if parameters are annotated with @json
.
We currently depend on a pre-RDF/JS version of N3.js.
This would allow better deduping and even tree shaking (since N3.js 1.2.0) in webpacked code.
When running CommunitySolidServer/CommunitySolidServer#358 on Node 10, it fails with
{ Error: Cannot find module '@solid/community-server'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at MappedNamedComponentFactory.<anonymous> (/home/runner/work/community-server/community-server/node_modules/componentsjs/lib/factory/UnnamedComponentFactory.js:197:43)
at Generator.next (<anonymous>)
at /home/runner/work/community-server/community-server/node_modules/componentsjs/lib/factory/UnnamedComponentFactory.js:7:71
at new Promise (<anonymous>)
at __awaiter (/home/runner/work/community-server/community-server/node_modules/componentsjs/lib/factory/UnnamedComponentFactory.js:3:12)
at Promise (/home/runner/work/community-server/community-server/node_modules/componentsjs/lib/factory/UnnamedComponentFactory.js:179:49)
at new Promise (<anonymous>) code: 'MODULE_NOT_FOUND' }
It works fine on Node 12.
I also think i did encounter this error on Node 12 in a different circumstance, but I cannot remember/reproduce.
Not urgent, since we will drop Node 10 anyway.
i noticed that the resolution code at
Components.js/lib/factory/UnnamedComponentFactory.ts
Lines 181 to 206 in 71be00e
requireName
, which can be costly.
Perhaps this should be a separate function with a cache?
A ComponentInstance
is a direct instance, that accepts no further params (such as the RDF/JS datafactory).
We should detect if the user tries to assign args on such instances, and throw an error (or at least emit a warning).
I'd like to inject a raw property into my component (a string, number, or raw JSON variable). For example, I have this component:
interface SomeJsonInterface {
a: string;
b: {
c: string;
d: number;
}
e: number[];
}
interface SomeComponentArgs {
someString: string;
someNumber: number;
someJson: SomeJsonInterface;
}
export class SomeComponent {
constructor(args: SomeComponentArgs) {
// ...
}
}
How would I wire up this component in the configuration?
As this package uses a very old version of n3.js it inherits this issue:
rdfjs/N3.js#134
When a constructor requires a (mandatory) list as argument, currently the instantiattion fails if the list passed in the configuration is empty ("ClassName:_listParam": []
). Is there a workaround for this behavior?
An experimental typeScopedContexts
flag has been added to Components-Generator.js that allows config files to be written in the form of aclManager
instead of WebAclAuthorizer:_aclManager
, without having the chance of clashing with other classes.
At the time of writing, when this flag is enabled in the Solid community server, this results in a massive overhead.
This is caused by how the JSON-LD context parser library handles type-scoped contexts. Disabling context validation reduces overhead a bit, but it still takes 4 seconds (instead of 0,5 seconds without this feature).
One solution might be to both disable context validation and reuse the compiled context for each parsed JSON-LD file.
Other solutions might be better and possible.
It would be good to throw an error when an import is not found. At the moment it looks like imports that are not found are silently ignored.
In case Components.js is run in a situation where the TypeScript sources are available, perhaps it would be interesting to run those instead of the JavaScript. This can save the need to build a project (and also there being 2 versions of code in memory in case other ways of instantiation are used too).
The source currently says that
It is assumed that the given package contains an index.d.ts file.
but its actual location should be read from the types
property of package.json
.
I wonder if the code at https://github.com/LinkedSoftwareDependencies/Components.js/blob/v3.6.1/lib/factory/UnnamedComponentFactory.ts#L191-L194:
// Always require relative from main module, because Components.js will in most cases just be dependency.
object = require.main.require(requireName.charAt(0) === '.'
? Path.join(process.cwd(), requireName)
: requireName);
should actually be:
object = require(requireName.charAt(0) === '.'
? Path.join(process.cwd(), requireName)
: require.resolve(requireName, { paths: [ Util.getMainModulePath() ] }));
I currently have a folder structure as follows:
projects
solid-hue
node_modules
../../community-solid-server
community-solid-server
node_modules
componentsjs
So when I invoke the server from community-solid-server
with solid-hue
as mainModulePath
, the componentsjs
function require
will not find community-solid-server
solid-hue
because it is in a different tree.
Therefore, I think that module resolution should be relative to the mainModulePath
.
Wasn't sure how to clearly phrase accurately, or if this is something that can be solved. The problem is that type-scoped context only work in blocks where the @type
key is present. For example: I define an instance in a file such as:
{
"@context": "https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^0.0.0/components/context.jsonld",
"@graph": [
{
"comment": "Supports default Solid behaviour on any kind of data accessor.",
"@id": "urn:solid-server:default:ResourceStore_DataAccessor",
"@type": "DataAccessorBasedStore",
"identifierStrategy": { "@id": "urn:solid-server:default:IdentifierStrategy" },
"auxiliaryStrategy": { "@id": "urn:solid-server:default:AuxiliaryStrategy" }
}
]
}
In another file I then want to import this class and link it to a data accessor like this:
{
"@id": "urn:solid-server:default:ResourceStore_DataAccessor",
"accessor": {
"@id": "urn:solid-server:default:MemoryDataAccessor"
}
}
This doesn't work though: Components.js will error here that the accessor
predicate is not defined since I guess the type-scoped context doesn't work there since the type field is set somewhere else. Would be nice if there was some way to also make it work there.
For example, the following parameter:
{
"@id": "caam:Actor/AbstractMediaTypedFixed/MediaTypeEntry/priority",
"comment": "A media type priority, with values between [0, 1]",
"default": "1",
"range": "xsd:float",
"required": true,
"unique": true
}
should result in a number type when compiled.
Instead, it shows up as 'priorityScale': '3.0E-1',
.
Full config: https://github.com/comunica/comunica/blob/master/packages/actor-abstract-mediatyped/components/Actor/AbstractMediaTypedFixed.jsonld#L33-L40
Can be reproduced by running yarn run prepare
in Comunica's actor-init-sparql and checking engine-default.js
.
Components.js 4.0.5 on Node 14.
Even though this project was designed for Node.js, we should consider making it compatible with Deno as wel.
It could be a great speed-up if software components are only loaded when needed.
Fully implementing this might require architectural changes, but perhaps some tweaks like this one could be implemented.
Module, component and config files should be validatable using an external tool, so that this for example could be included in the CI pipeline of other projects.
Things like proper parameter definitions, valid extensions and valid context shortcut usages should be checked.
Is it currently possible to somehow inject functions into components? If not, how hard would it be to implement?
A Record<string, number>
parameter generated by the Components.js generator looks like this:
{
"@id": "scs:dist/storage/conversion/QuadToRdfConverter#QuadToRdfConverter_options_outputPreferences",
"range": {
"@type": "scs:dist/storage/conversion/QuadToRdfConverter#QuadToRdfConverter_options_outputPreferences_range",
"parameters": [
{
"@id": "scs:dist/storage/conversion/QuadToRdfConverter#QuadToRdfConverter_options_outputPreferences_key",
"required": true,
"unique": true
},
{
"@id": "scs:dist/storage/conversion/QuadToRdfConverter#QuadToRdfConverter_options_outputPreferences_value",
"range": "xsd:number",
"required": true,
"unique": true
}
]
}
}
Note in particular the range ofxsd:number
(which I don't think exists, but Components.js also has it in its source code).
However, specifying the object as
"QuadToRdfConverter:_options_outputPreferences": [
{
"QuadToRdfConverter:_options_outputPreferences_key": "text/turtle",
"QuadToRdfConverter:_options_outputPreferences_value": 1
}
]
will convert the number to a string.
Currently, instantiateFromUrl
allows specifying one componentUrl
.
It would be interesting to specify an array and get back a key/value object.
Sorry this is more a question than an issue, but I'm just wondering what the best way of using components.js
in the browser is? I can see that in comunica the components.js config has to be compiled initially before being sent to webpack. Is this the only way to do it at the moment? I'd love to experiment with the project a bit but all of my dev is in the browser so I just want to make sure I'm not missing anything before proceeding. Thanks!
Feel free to close the issue, if it doesn't fit here in this repository. I cannot found any other place.
It seems lsd project and ontology is language agnostic. It will be great, if ontology supports expressing Algebraic data types, so that we can model rust's enums , or haskell's enums etc. with this ontology.
Thanks for your work.
Or at least provide an option to use relative paths instead of absolute paths.
This could be done by somehow exposing parts of ConfigConstructorPool
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
node
, @types/node
)@typescript-eslint/eslint-plugin
, @typescript-eslint/parser
)package.json
@rdfjs/types *
@types/minimist ^1.2.0
@types/node ^18.0.0
@types/semver ^7.3.4
jsonld-context-parser ^2.1.1
minimist ^1.2.0
rdf-data-factory ^1.1.0
rdf-object ^1.14.0
rdf-parse ^2.0.0
rdf-quad ^1.5.0
rdf-string ^1.6.0
rdf-terms ^1.7.0
semver ^7.3.2
winston ^3.3.3
@rubensworks/eslint-config ^1.0.1
@types/jest ^29.0.0
@types/stream-to-array ^2.3.0
@types/streamify-string ^1.0.0
@typescript-eslint/eslint-plugin ^5.0.0
@typescript-eslint/parser ^5.0.0
jest ^29.0.0
jest-mock ^29.0.0
jest-rdf ^1.8.0
jshint ^2.1.10
manual-git-changelog ^1.0.1
n3 ^1.11.1
node-polyfill-webpack-plugin ^3.0.0
pre-commit ^1.2.2
simple-copy ^2.2.1
stream-to-array ^2.3.0
streamify-string ^1.0.1
ts-jest ^29.1.0
ts-loader ^9.4.1
typescript ^5.0.0
webpack ^5.75.0
webpack-cli ^5.0.0
yarn 4.0.1
.nvmrc
node 18
If there is a circular dependency in the Components.js config, e.g. A takes B as input and B takes A as input, the result would be that one of the two gets undefined
as input value instead of the expected instance. It makes sense that they can't reference each other since one of them has to be instantiated first, but it would be nice if Components.js threw an error in such a case instead of using undefined
.
The example above is quite simplistic of course, in practice this might occur in much larger chains.
Currently, if the main package is being required, but an error occurs during loading of that package, then a generic error is being thrown, and the actual error message why the require failed is silenced.
We should ensure that the error is caught and kept track of here:
I'd like to be able to instantiate a variable with a component reference.
For example, I'd like to instantiate
{
"@id": "urn:solid-server:default:variable:store",
"@type": "Variable"
}
with urn:solid-server:default:RoutingResourceStore
defined elsewhere in the configuration file.
We might need a special class for that, such as IriRef
, that we pass as a variable value.
(Note that NamedNode
wouldn't work, because then we would be unable to pass actual named nodes. It has to be a value that would never be used otherwise.)
Editing plain-text when writing components and config files can be difficult.
It would be good if we allow these to be edited with the typical IDE features, such as code completion, validation and pre-complication to see the intended model.
Intellij for example has a custom language API: http://www.jetbrains.org/intellij/sdk/docs/reference_guide/custom_language_support.html
Instead of using N3.js's custom triple representation for streams, we should support the RDFJS spec.
This depends on rdfjs/N3.js#118.
null
parameters are converted to undefined
Example:
{
"@id": "http://example.org/myInstance",
"@type": "ex:MyModule/MyComponent",
"ex:MyModule/MyComponent#name": null
}
would create object
{ name: undefined }
Is this intentional?
UNIX
Components.js v4.0.5
Components.js generator v2.1.0
Node.js v14
/
Variables have been added to Components.js in v3.6.0. We can set them programmatically: https://github.com/solid/community-server/blob/e1533a0869071bbeabf0edfdfd05ccf57883cdaa/src/init/CliRunner.ts#L42-L46
However, could I also give them a value inside the Components.js config? CommunitySolidServer/CommunitySolidServer@1dd140a#diff-fec64cbd09e800f0351eb81eaaef521a1b9fecef9f81a3584d513e4f1266b6c0R4-R15
That might be handy to propagate string/number values around.
Component and module files can require a lot of manual work.
A large part of this could be autogenerated using code inspection and based on the available JSDoc.
Also relevant:
https://github.com/buehler/node-typescript-parser
Requirements:
I am trying to create a Turtle configuration. It starts as follows:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix css: <https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/>.
@prefix config: <https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/%5E0.0.0/config/presets/>.
@prefix config-ldp: <https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/%5E0.0.0/config/presets/ldp/>.
@prefix config-backend: <https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/%5E0.0.0/config/presets/backend/>.
<> rdfs:seeAlso
config:acl.json.
Note the usage of %5E
rather than ^
, which is not a valid URI character and needs to be escaped.
This crashes with:
Error: Error while parsing file "https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/%5e0.0.0/config/presets/acl.json": Unexpected "E" at position 0 in state STOP
latest on macOS
Error: Error while parsing file "https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/%5e0.0.0/config/presets/acl.json": Unexpected "E" at position 0 in state STOP
at Function.addPathToError (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/componentsjs/lib/rdf/RdfParser.js:69:16)
at PassThrough.<anonymous> (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/componentsjs/lib/rdf/RdfParser.js:42:38)
at PassThrough.emit (events.js:327:22)
at JsonLdParser.<anonymous> (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/componentsjs/node_modules/rdf-parse/lib/RdfParser.js:71:47)
at JsonLdParser.emit (events.js:327:22)
at Parser.jsonParser.onError (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/jsonld-streaming-parser/lib/JsonLdParser.js:370:18)
at Parser.proto.charError (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/jsonparse/jsonparse.js:90:8)
at Parser.proto.write (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/jsonparse/jsonparse.js:154:23)
at JsonLdParser._transform (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/jsonld-streaming-parser/lib/JsonLdParser.js:110:25)
at JsonLdParser.Transform._read (_stream_transform.js:191:10)
I am working on an external module to @solid/community-server
. My module is named solid-hue
; not yet published on npm.
I start creating my configuration config-hue.json
as follows:
{
"@context": [
"https://linkedsoftwaredependencies.org/bundles/npm/solid-hue/^0.0.0/components/context.jsonld",
"https://linkedsoftwaredependencies.org/bundles/npm/@solid/community-server/^1.0.0/components/context.jsonld"
]
}
However, when running the command community-solid-server -c config/config-hue.json
, I get:
jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context.
at Array.done (/Users/ruben/Documents/UGent/Solid/solid-community-server/node_modules/jsonld/js/jsonld.js:6841:19)
This is understandable, given that @solid/community-server
does not know about the package.json
contents of my solid-hue
, which has the local aliases:
"lsd:module": "https://linkedsoftwaredependencies.org/bundles/npm/solid-hue",
"lsd:components": "dist/components/components.jsonld",
"lsd:contexts": {
"https://linkedsoftwaredependencies.org/bundles/npm/solid-hue/^0.0.0/components/context.jsonld": "dist/components/context.jsonld"
},
"lsd:importPaths": {
"https://linkedsoftwaredependencies.org/bundles/npm/solid-hue/^0.0.0/components/": "dist/components/",
"https://linkedsoftwaredependencies.org/bundles/npm/solid-hue/^0.0.0/config/": "config/",
"https://linkedsoftwaredependencies.org/bundles/npm/solid-hue/^0.0.0/dist/": "dist/"
},
What would be a convenient way for developers to resolve this?
The idea is to add an option so values that have been set in a different (imported) config can be overridden. For example in CSS we have the following config:
{
"@id": "urn:solid-server:default:ResourceLocker",
"@type": "WrappedExpiringReadWriteLocker",
"locker": { ... },
"expiration": 3000
}
This is one of the configs that gets imported into the main config to set up the locking system. If a user wants to change the expiration time of the locks, they would have to copy everything in this import somewhere else, change the expiration value, and import that config instead (or copy it into the main config).
It would be nice if instead something like this could be added to the main config instead:
{
"@id": "urn:solid-server:default:ResourceLocker",
"@override": {
"WrappedExpiringReadWriteLocker:_expiration": 5000
}
}
Which would make it much easier for users to adapt existing configurations.
The disadvantage (besides potentially being complex to implement) is that if you start from a config that already has an override value, there is no way to override it again. Perhaps a weight system could be used there but that would increase complexity.
Potentially there are also other possible solutions, but in general the ability to change the value of a parameter from an imported config would make several situations much easier.
Cleanup promise usage with async/await keywords.
When working on CSS, we noticed that our validation script went from seconds to minutes between 3.x and 4.x:
componentsjs-compile-config urn:solid-server:default:Initializer -c config/default.json -f > /dev/null
4.x
It could be useful to have a way to link to the same object with multiple identifiers. Example below from the community solid server:
For the CSS config I was thinking of having separate config files for every class that would be instantiated. This way you could have intermediate configs that only import the classes that are needed for a config, which would make it easy to create new combinations of classes without having to copy/paste potentially large blocks. E.g., monitoring-store.json
would just contain
{
"@id": "urn:solid-server:default:MonitoringStore",
"@type": "MonitoringStore",
...
},
The one issue with this that some components are referenced by several other classes. One of these is the urn:solid-server:default:ResourceStore
. In practice this is a MonitoringStore
, so two options I see are:
monitoring-store-default.json
where the identifier is set to that one instead. This would place more work on people who want to make new combinations of the configs though.urn:solid-server:default:ResourceStore
. Definitely would not do this since this would require a lot of changes every time.It would be nice if I could just write urn:solid-server:default:ResourceStore owl:sameAs urn:solid-server:default:MonitoringStore
since that only requires a single change there for new configs.
Note that in practice the first option would not be that horrible right now as the changes are still not that drastic, but I do think the sameAs
solution might also be helpful in several other situation to streamline configurations.
In 08b7950, we introduced the rdf:JSON
param range, which allows users to pass arbitrary JSON values.
While useful for many cases, this strips away any kind of type-checking,
which may result in cases where an unexpected JSON shape is received.
Example where myParam
expects a Record<string, string>
:
{
"@id": "ex:myInstance",
"@type": "ex:MyClass",
"ex:myParam": {
"key1": "value1",
"key2": "value2"
}
}
So this would have to be converted into:
<ex:myInstance> a ex:MyClass;
ex:myParam [ ex:key "key1"; ex:value "value1" ],
[ ex:key "key2"; ex:value "value2" ].
AFAICS, JSON-LD currently doesn't support such functionality.
JSON-LD's property-based data indexing already gets us partially there (defining the key's as index range), but the keys would not allow direct values in that case.
Following the steps here:
mkdir my-server
cd my-server
npm install @solid/[email protected] solid-hue
npx community-solid-server -c settings.json -m .
results in
2021-01-16T19:14:52.543Z [Components.js] info: Initiating component discovery from /Users/ruben/Desktop/my-server
2021-01-16T19:14:52.546Z [Components.js] info: Discovered 0 component packages within 0 packages
2021-01-16T19:14:52.547Z [Components.js] info: Initiating component loading
2021-01-16T19:14:52.549Z [Components.js] info: Registered 0 components
but when I add an empty package.json
file:
echo '{}' > package.json
it suddenly works:
2021-01-16T19:15:38.275Z [Components.js] info: Initiating component discovery from /Users/ruben/Desktop/my-server
2021-01-16T19:15:38.332Z [Components.js] info: Discovered 30 component packages within 241 packages
2021-01-16T19:15:38.333Z [Components.js] info: Initiating component loading
2021-01-16T19:15:38.850Z [Components.js] info: Registered 158 components
This seems to be a deliberate choice:
Components.js/lib/loading/ModuleStateBuilder.ts
Lines 113 to 114 in 3ba6dca
but I think the better check would actually be the presence of a node_modules
path (or at least an OR with that).
The codebase is not very clean/consistent in some places, let's fix some of this by adding a tslint file.
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.