Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PR: Incremental refactoring to web-modules #167505 #12

Open
16 of 39 tasks
Tracked by #15
, #167505
...
lemanschik opened this issue Dec 5, 2022 · 0 comments
Open
16 of 39 tasks
Tracked by #15
, #167505
...

PR: Incremental refactoring to web-modules #167505 #12

lemanschik opened this issue Dec 5, 2022 · 0 comments

Comments

@lemanschik
Copy link
Contributor

Current

Why? in this issue

This solves the so called resolveMethod problems cross runtimes and enables so easier error free references.
which enables dependent projects to refactor the build and we can all share again the same codebaase
as we agree on a build able module standard that we all can share. the rest is only a sideEffect

This builds on the following ECMAScript Module Design Principles

  1. Build valid ECMAScript Spec Compliant Modules
  2. If you use bar specifiers or none js code assets you need to supply loader and resolveId hooks.

Auditability and readability of your code is the highest principle to make it easy use able by others. Runtime Optimization gets done via Jit on execution you as the developer do not need to optimize for the runtime.

a runtime gets used and is designed for the code optimization it self and can do it better then you almost always. And at last always repeatable and so scaleable for all.

Creating code-oss (code Open Source Studio)

a p2p code environment that can connect to other environments including private and public shared build grids for your software stacks and deployments. Allows live development with the whole web in real time.

This issue tracks the transformation of the code-oss build process it self into the first existing full implementation of web-modules as also will be the first consumer of it to build it self. So this is like with the creation of coding languages we take the existing one till our own can build it self.

web-modules has evolved the infrastructure of the Web,

with many things we've learned from successful systems, like Git, BitTorrent, Kademlia, Bitcoin, and many, many more. This is the sort of thing that would have come out of ARPA/DARPA, IETF, or Bell Labs in another age. Web 4.0 state 2 after genesis boot so V_ETH2 on top of WebRTC for interop with the existing legacy web.

addressed by content and references so called specifiers. It enables the creation of completely distributed applications, and in doing so aims to make the web faster, safer, and more open.

see: a early example https://beakerbrowser.com/
see: Web Modules - The Standard for the Web 4.0 https://github.com/lemanschik/web-modules/blob/main/README.md

Ecosystem dependent

Iteration Tracking

first iteration:
Will Incremental upgrade the build will let it as is produce the AMD loader will merge the AMD loader in under build/ as it is build related. will incremental switch over parts project size is to big for a batch upgrade. I got good progress with incremental commits.

secund iteration

  • Partial: start replacing the AMDLoader from inside to outside reverse of control pattern for functions.
  • Add: below bespoken external code-oss-resolver.js

backlog:

some nice additional demos as context

History

i would love to chain this with:

This Proposes to algin the engineering labeled tasks that are related to the ESM Build creation and the vscode-loader (AMD) to port the AMD Resolution algos in a compatible way to the NodeJS --import and --require flags respectivly so that it would enable shared loader resolution

Execution Plan

A Resolution map needs to exist it can be generated via typescript. a PR is WiP to show the concept.

esm.js it is importent to keep that as esm file for compat and import.meta.url usage as smallest patch able modifier.

// Slash at the end is importent for relativ bases to start without
// explicitly setting ./  on each dependencie so keep current style
export const baseUrl = new URL(import.meta.url).path + 'code-oss-dev/src' + '/'
// vscode internal specifiers resolution 
export const vscodeResolve = {
  'specifier': 'relativeToAbsoulteBaseUrl',
// Needs to be relativ logic less if that is to much we can shorten that with import maps compatible string replace 
// patterns it is the same concept that nodeNext resolve uses in typescript implemented via package.json exports.
// there can be only 1 x * char in the string it gets replaced 1:1 with the right hand side of the object 
   'vs/*': baseUrl + 'vs/*.js' // requesting vs/my-module  will be resolved to the most specific 
  // match of the left hand see vscodeVirtualResolved
}

// isRelative ./ or bare xx or absolute /
// turn all into absolute from vscodeResolve via use of baseUrl  turn relative into absolute via baseUrl turn bare to absolute via vscodeResolve use new URL(any, baseUrl) where any should already be none relative via new URL(any, import.meta.url);
// (modSpecifier) => moduleSpecifier
// const getAll parts of vscodeResolve before the * turn that into absolute 

// We need to implement nodeNextResolve as that is not implemented in typescript it self the current node next is fake and does not even support import conditions. 


// this is only to show the in memory view
const vscodeVirtualResolved = {
  'specifier': 'relativeToAbsoulteBaseUrl',
  // 'vs/*': baseUrl + 'vs/*.js',
   'vs/my-module': baseUrl + 'vs/my-module.js',
}
// this creates shared memory references on each import with a other url
export const resolvedId = baseUrl + (`...code here resolves import.meta.url params to return a result on import`)

// above gets static typed internal with valueof keyof Type Const the map will be even accessible in the IDE.

The above is pseudo code to show more readable the importent parts later tagged template strings are favored.

Module usage example same sandbox

all context share the same module reference to the resolution result in memory worker service worker all tabs all that belongs to the same URL

import('vscode-resolve?id=vs/editor').then( ({ resolvedId }) => import(resolvedId) );
    ## example greenfield imports 

import('vscode-resolve?id=vs/editor').then( ({ resolvedId }) => import(resolvedId) );

the trick is that we use import meta parse the url parms in the resolver and this way get share able in memory references

this leads to directly in memory pointers that are cross isolate scope shareAble

the internal module cache will return the same module by url as the cache is url indexed it returns a reference to the same instance

<script type="module">import('vscode-resolve?id=vs/editor').then( ({ resolvedId }) => import(resolvedId) );</script>
<script type="module">import('vscode-resolve?id=vs/editor').then( ({ resolvedId }) => import(resolvedId) );</script>

only one instance in memory total shared can be referenced also in shadow Dom i use that to share CSS at scale

we can call the below pattern css modules it saves us from the hoax that css gets its own lang today.

import css from ''; // returns css = { color: "red" }
Object.assign(el.style, { color: "red" })

also note at scale this references only one time the utf8 string red in memory! and one additional pointer reference 1 byte

Originally posted by @lemanschik in rollup/rollup#4729 (comment)

Action able items

  • Do stop relativ path transformation in the source like you do in your current ESM Loader transformation.
  • Implement above bespoken resolve module that is reuseable cross ecosystem and context.
  • Use Rollup as Loader API and do not create a migration.js create build/plugin-migration.js
    • We need to build the src only 1x as ESM this will produce namedExports this type declarations will get 1:1 reused shared with the CJS build and ESM while CJS makes Only sense to run the existing tests till all are upgraded
    • const buildTscCache = () => tsc --module esnext --target esnext
  • https://github.com/microsoft/monaco-editor/blob/main/webpack-plugin/src/loaders/include.ts this was maybe the old loder

Closes also
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lemanschik