Local context lookup?

[renyuneyun]

I'm trying to understand some software (solid-calendar-store) that uses components.js, and am reading the components.js documents. I believe I got the basic concepts, but am struggling with some details.
The current main burden is the context specification and lookup from components.js. It may also relate to componentsjs-generator (not mentioned yet).

What I do not understand and my question

In the document of components.js, under the section quick start (TypeScript), it creates a local package and then uses a URL on a remote server for it in the context https://linkedsoftwaredependencies.org/bundles/npm/my-package/^2.0.0/components/context.jsonld.

This package is at local filesystem, and therefore the information is not published to a remote server at all. Therefore, the URL should be invalid.

However, the document says it works in this way. This makes me very confused.

What I understand

It is intuitive if the context document is published on a remote URL, e.g. https://linkedsoftwaredependencies.org/bundles/npm/componentsjs/^5.0.0/components/context.jsonld. Component.js will download this document and interpret it (as ontology?).

As I saw from solid-calendar-store, although using some complicated/advanced mechanisms, the package.json file defined a context overridden for the remote context document to a local file (which is generated by componentsjs-generator. This is also understandable.

I also read #29 #30. But they did not help me eliminate the question.

[rubensworks]

When Components.js encounters a context URL such as https://linkedsoftwaredependencies.org/bundles/npm/my-package/^2.0.0/components/context.jsonld, it will first try to resolve this context via the installed dependencies within your node_modules directory (which can be exposed by my-package). Only if it can not resolve this context locally, it will fallback to resolving the context by following the URL.

This local resolution can indeed be done via context overrides in the package.json as you pointed out. However, if you don't define a custom context override, but you add "lsd:module": true to your package.json, it will by default provide a context override for the context at components/context.jsonld.

In the initial Components.js version, contexts were always fetched from the URL. But because this slowed down the dependency injection process a lot, we added these local overrides. So if the context is being fetched from the URL instead of the local file system, something is probably going wrong.

Does this clarify your question?

[renyuneyun]

Thanks very much for the answer! I read the (second) link and it is very useful.
I can understand the local resolution from the conceptual aspect, but still have questions about details (still based on TypeScript quick start):

1. How does it work with the current package that I'm developing? I presume the current package is not placed into node_modules? (Please correct me if I'm wrong. I'm still new to JavaScript.)
2. I believe the componentsjs-generator tool should be run (as stated in the document) to generate the context file for the current package before the application is run. It generates a local context file somewhere that can be automatically picked up by components.js. What's the relation between components (components.jsonld) and contexts (context.jsonld)? How does it decide the version? (Probably related, does ^2.0.0 cover 2.3.1 for context look up?)
3. Does the context look up (for context https://linkedsoftwaredependencies.org/bundles/npm/some-package/^2.0.0/components/context.jsonld) finds in node_modules for a file some-package/components/context.jsonld, and then checks if its version specified matches 2.0.0?

[rubensworks]

How does it work with the current package that I'm developing? I presume the current package is not placed into node_modules? (Please correct me if I'm wrong. I'm still new to JavaScript.)

That's a good question!
The current package is indeed not present in the node_modules directory, so Components.js has an internal workaround for finding the current package. As long as you correctly set the mainModulePath when building a ComponentsManager to the current package root, it will be able to identify this package as the current package.

I believe the componentsjs-generator tool should be run (as stated in the document) to generate the context file for the current package before the application is run. It generates a local context file somewhere that can be automatically picked up by components.js. How does it decide the version? (Probably related, does ^2.0.0 cover 2.3.1 for context look up?)

The version will be determined based on the "version" field in your package.json file. It will always pick the major version. So if your version is 2.3.1, it will set the context URL to use ^2.0.0.

What's the relation between components (components.jsonld) and contexts (context.jsonld)?

Components are JSON-LD representation of your classes and parameters. Contexts just enable the shortening of URLs, so that for example paramX can be used instead of http://...paramX.

Does the context look up (for context https://linkedsoftwaredependencies.org/bundles/npm/some-package/^2.0.0/components/context.jsonld) finds in node_modules for a file some-package/components/context.jsonld, and then checks if its version specified matches 2.0.0?

Components.js will discover packages that expose context files, and only for those, it will use local context lookups instead of remote lookups.