Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orion/Dependency resolution"
< Orion
Line 6: | Line 6: | ||
* <tt>importScripts( urls.. )</tt> in a JS file (web worker API) | * <tt>importScripts( urls.. )</tt> in a JS file (web worker API) | ||
− | Dependency resolution is a prerequisite feature to cross-file type inference and content assist. | + | Dependency resolution is a prerequisite feature to cross-file type inference and content assist. |
+ | |||
+ | === Minimally Useful Case === | ||
+ | * Allow user to ctrl+click a CSS <tt>@import</tt> to open the imported file in an editor tab. | ||
=== Concepts === | === Concepts === | ||
* '''Dependency''': a reference to some ''logical path'' (LP). | * '''Dependency''': a reference to some ''logical path'' (LP). | ||
− | * '''Logical path''' (LP): whatever goes inside the src=" | + | * '''Logical path''' (LP): whatever goes inside the <tt>src="___"</tt>, <tt>@import "___"</tt>, <tt>require(___)</tt>, etc. |
** The LP is opaque to everything but a Resolver, which can translate LP to a workspace path. | ** The LP is opaque to everything but a Resolver, which can translate LP to a workspace path. | ||
** Example: in JS, depending on the context, the LP can be a commonJS module path (Node.js), a path in the local file system (Node.js), a web path (browser/worker), or an AMD module ID. | ** Example: in JS, depending on the context, the LP can be a commonJS module path (Node.js), a path in the local file system (Node.js), a web path (browser/worker), or an AMD module ID. | ||
* '''Resolver''': resolves a LP to a workspace path (WP). | * '''Resolver''': resolves a LP to a workspace path (WP). | ||
− | ** | + | ** WPs can be fetched/parsed using the usual Orion FileClient API. |
− | * '''Web Path | + | * '''Web Path Definition''' (WPD): captures the path-translation info necessary to map from an LP that is a web location. |
** The notion of WPD is important because a resource's location on a web server is generally not the same as its location in the workspace. For example, a file located at a repo path of <tt>/src/webapp/static/js/foo.js</tt> may be exposed on the web as <tt>/admin/js/foo.js</tt>. | ** The notion of WPD is important because a resource's location on a web server is generally not the same as its location in the workspace. For example, a file located at a repo path of <tt>/src/webapp/static/js/foo.js</tt> may be exposed on the web as <tt>/admin/js/foo.js</tt>. | ||
+ | ** The WPD | ||
** The WPD is of interest to any Resolvers that may encounter web paths as LPs. | ** The WPD is of interest to any Resolvers that may encounter web paths as LPs. | ||
** A WPD is a subset of the site structure defined by an Orion site configuration. Should factor out any commonality here. | ** A WPD is a subset of the site structure defined by an Orion site configuration. Should factor out any commonality here. | ||
Line 24: | Line 28: | ||
* What Resolver implementations do we need? | * What Resolver implementations do we need? | ||
* Which Resolvers leverage the WPD? | * Which Resolvers leverage the WPD? | ||
− | * Do we expect a stanza present in JS files to distinguish whether Node.js resolution or AMD should be used? (eg. <tt>/*eslint-env amd*/</tt> versus <tt>/*eslint-env node*/</tt>). | + | * Do we expect a stanza present in JS files to distinguish whether Node.js resolution logic or AMD should be used? (eg. <tt>/*eslint-env amd*/</tt> versus <tt>/*eslint-env node*/</tt>). |
* Expose a user action to select the '''root context''' (HTML file, JS script, etc) -- the base URL they're working against on the web. | * Expose a user action to select the '''root context''' (HTML file, JS script, etc) -- the base URL they're working against on the web. | ||
− | |||
− | |||
[[Category:Orion]] | [[Category:Orion]] | ||
[[Category:Orion/Tooling]] | [[Category:Orion/Tooling]] |
Revision as of 11:38, 14 October 2014
Dependency resolution refers to the ability to resolve a type of cross-file dependency to a file in the workspace at development time. Examples of dependencies within our scope are:
- src and href attributes in an HTML file
- @import statements and url( .. ) in a CSS file
- define([ deps.. ]) and require([ deps.. ]) in a JS file (AMD modules)
- require( "dep/path" ) in a JS file (Node.js/CommonJS)
- importScripts( urls.. ) in a JS file (web worker API)
Dependency resolution is a prerequisite feature to cross-file type inference and content assist.
Minimally Useful Case
- Allow user to ctrl+click a CSS @import to open the imported file in an editor tab.
Concepts
- Dependency: a reference to some logical path (LP).
- Logical path (LP): whatever goes inside the src="___", @import "___", require(___), etc.
- The LP is opaque to everything but a Resolver, which can translate LP to a workspace path.
- Example: in JS, depending on the context, the LP can be a commonJS module path (Node.js), a path in the local file system (Node.js), a web path (browser/worker), or an AMD module ID.
- Resolver: resolves a LP to a workspace path (WP).
- WPs can be fetched/parsed using the usual Orion FileClient API.
- Web Path Definition (WPD): captures the path-translation info necessary to map from an LP that is a web location.
- The notion of WPD is important because a resource's location on a web server is generally not the same as its location in the workspace. For example, a file located at a repo path of /src/webapp/static/js/foo.js may be exposed on the web as /admin/js/foo.js.
- The WPD
- The WPD is of interest to any Resolvers that may encounter web paths as LPs.
- A WPD is a subset of the site structure defined by an Orion site configuration. Should factor out any commonality here.
Questions (TODO)
- What is the basic interface of Resolver?
- What Resolver implementations do we need?
- Which Resolvers leverage the WPD?
- Do we expect a stanza present in JS files to distinguish whether Node.js resolution logic or AMD should be used? (eg. /*eslint-env amd*/ versus /*eslint-env node*/).
- Expose a user action to select the root context (HTML file, JS script, etc) -- the base URL they're working against on the web.