linkedsoftwaredependencies / components.js Goto Github PK

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.

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:

but I think the better check would actually be the presence of a node_modules path (or at least an OR with that).

Issue type:

• 🐛 Bug

Description:

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

Environment:

4.x

Crash log:

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

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.

Issue type:

• ➕ Feature request

Description:

Even though this project was designed for Node.js, we should consider making it compatible with Deno as wel.

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.

Issue type:

• ➕ Feature request

Description:

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?

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.

See LinkedSoftwareDependencies/Components-Generator.js#44

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!

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:

• Allow this tool to be called via CLI and via JS code.
• Parse TypeScript as AST.
• Detect whether or not a class is abstract.
• Detect constructors of classes.
• Discover from what class a class extends.
• Find all parameters in a class, and detect the correct type of each parameter.
• Serialize to JSON-LD (pretty-print).

This could be done by somehow exposing parts of ConfigConstructorPool

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.

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!

Issue type:

• ➕ Feature request

Description:

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.

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

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.

Issue type:

• 🐛 Bug

Description:

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:

Issue type:

• ➕ Feature request

Description:

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:

• Create a new config file 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.
• Change all config files that reference 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.

Issue type:

• ➕ Feature request

Description:

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.

Issue type:

• 🐛 Bug

Description:

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.

Environment:

Components.js 4.0.5 on Node 14.

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?

Issue type:

• ➕ Feature request

Description:

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.

Issue type:

• ➕ Feature request

Description:

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.

Issue type:

• ➕ Feature request

Description:

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.

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)

Issue type:

• ➕ Feature request

Description:

Is it currently possible to somehow inject functions into components? If not, how hard would it be to implement?

Issue type:

• 🐛 Bug

Description:

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?

Environment:

UNIX
Components.js v4.0.5
Components.js generator v2.1.0
Node.js v14

Crash log:

/

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

Issue type:

• ➕ Feature request

Description:

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.

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

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.

The codebase is not very clean/consistent in some places, let's fix some of this by adding a tslint file.

Cleanup promise usage with async/await keywords.

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.

Currently, instantiateFromUrl allows specifying one componentUrl.
It would be interesting to specify an array and get back a key/value object.

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?

Issue type:

• 🐛 Bug

Description:

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

Environment:

latest on macOS

Crash log:

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

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.

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?

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.

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.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update Yarn to v4.0.2
• Update dependency @rubensworks/eslint-config to v2
• Update dependency node to v20 (node, @types/node)
• Update typescript-eslint monorepo to v6 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

As this package uses a very old version of n3.js it inherits this issue:
rdfjs/N3.js#134

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

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
      • symlink to ../../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.

Instead of using N3.js's custom triple representation for streams, we should support the RDFJS spec.

This depends on rdfjs/N3.js#118.

i noticed that the resolution code at

Perhaps this should be a separate function with a cache?