webpack/browserify compatible AMD headers

Hello,
Is there any way to change AMD headers to be compatible with webpack/browserify?
Are there any plans to support CommonJS, UMD  or ECMAscript 6 for the package and external modules in  monaco.d.ts?

+1
I want to use it in my app, but i cant because use webpack for modules.

https://webpack.github.io/docs/amd.html
I thought webpack understands AMD code? What more should be done on our side to get the editor loader with webpack?

I think webpack parses headers(imports/exports) and obviously using the constructs like https://github.com/Microsoft/vscode/blob/master/build/lib/bundle.ts#L278 breaks parsing.

Well, the editor.main.js that ships is already packed (contains 500+ AMD modules). Is the intent here to repack it (run the editor.main.js + all the javascript files we ship) through webpack? I have not used webpack so I'm not sure what we can do on our side... Should we also ship an unbundled/unpacked version where each AMD module sits in its own file?

@alexandrudima i tried to use monaco in my script like that:
require(['vs/editor/editor.main'], function() {
    var editor = monaco.editor.create(document.getElementById('container'), {
        value: [
            'function x() {',
            '\tconsole.log("Hello world!");',
            '}'
        ].join('\n'),
        language: 'javascript'
    });
});

But it dosent work because Webpack cant find "edcore.main" for example, because he try to find it like file in "vs/editor" folder.
Log:
Module not found: Error: Cannot resolve module 'vs/editor/edcore.main' in src/js/vendor/vs/editor
resolve module vs/editor/edcore.main in src/js/vendor/vs/editor
  looking for modules in bower_components
    bower_components/vs doesn't exist (module as directory)
  looking for modules in src/js/vendor
    resolve 'file' or 'directory' editor/edcore.main in src/js/vendor/vs
      resolve file
        src/js/vendor/vs/editor/edcore.main doesn't exist
        src/js/vendor/vs/editor/edcore.main.web.js doesn't exist
        src/js/vendor/vs/editor/edcore.main.webpack.js doesn't exist
        src/js/vendor/vs/editor/edcore.main.js doesn't exist
        src/js/vendor/vs/editor/edcore.main.json doesn't exist
      resolve directory
        src/js/vendor/vs/editor/edcore.main doesn't exist (directory default file)
        src/js/vendor/vs/editor/edcore.main/package.json doesn't exist (directory description file)
[bower_components/vs]
[src/js/vendor/vs/editor/edcore.main]
[src/js/vendor/vs/editor/edcore.main.web.js]
[src/js/vendor/vs/editor/edcore.main.webpack.js]
[src/js/vendor/vs/editor/edcore.main.js]
[src/js/vendor/vs/editor/edcore.main.json]

Maybe unpacked version will be work.

@alexandrudima, yes I think shipping not bundled amd modules would definitely work for webpack.
@MazheM  before you can see the error I faced you need to remap paths: 'vs':  path.join(__dirname, 'node_modules/monaco-editor-core/dev/vs/'
https://webpack.github.io/docs/resolving.html

To be totally honest I believe that main npm package should only contain CommonJS version + d.ts with external modules. Bundles for different formats amd, umd etc(and ambient d.ts) should be distributed as bower or jspm packages, or at least as secondary npm packages.

@NikGovorov Yes, i know it. I placed monaco to src/js/vendor/vs and in webpack config i have modulesDirectories: ['node_modules', 'src/js/vendor'],

I would also appreciate some examples or help on how to get it to run with webpack.
I tested the following approaches:
Added to webpack resolve configuration:
resolve: {
    alias: {
        vs: path.resolve(__dirname, 'node_modules/monaco-editor/dev/vs'),
    },

and did
require('vs/editor/editor.main')

in my main module.
Alternatively to the second step I also tried putting the following in the plugins section of webpack:
new webpack.ProvidePlugin({
       "monaco": "monaco-editor/dev/vs/editor/editor.main"
    }),

Both end up with missing references to edcore.main and fs (which is referenced by typescriptServices.js - but fs is a node module and shouldn't be available in the browser?)

@alexandrudima is any update on this?

I got monaco working now with webpack and angular2.
What I did:
Configure webpack to simply copy the bundled monaco version to my output directory with CopyWebpackPlugin:
plugins: [
    new CopyWebpackPlugin([
        {
            from: 'node_modules/monaco-editor/min/vs',
            to: 'vs',
        }
    ]),
],

and build a monaco angular2 component that loads the AMD loader if required and then loads monaco as a global variable:
import { Component, ViewChild, ElementRef, ViewQuery }
         from '@angular/core';
import { COMMON_DIRECTIVES  }
         from '@angular/common';

import * as _ from 'lodash';

declare const monaco: any;
declare const require: any;

@Component({
  selector: 'ctc-monaco-editor',
  directives: [COMMON_DIRECTIVES],
  template: `

  `,
})
export class MonacoEditor {
  @ViewChild('editor') editorContent: ElementRef;

  constructor(
  ) {
  }

  ngAfterViewInit() {
    var onGotAmdLoader = () => {
      // Load monaco
      (<any>window).require(['vs/editor/editor.main'], () => {
        this.initMonaco();
      });
    };

    // Load AMD loader if necessary
    if (!(<any>window).require) {
      var loaderScript = document.createElement('script');
      loaderScript.type = 'text/javascript';
      loaderScript.src = 'vs/loader.js';
      loaderScript.addEventListener('load', onGotAmdLoader);
      document.body.appendChild(loaderScript);
    } else {
      onGotAmdLoader();
    }
  }

  // Will be called once monaco library is available
  initMonaco() {
    var myDiv: HTMLDivElement = this.editorContent.nativeElement;
    var editor = monaco.editor.create(myDiv, {
      value: [
        'function x() {',
        '\tconsole.log("Hello world!");',
        '}'
      ].join('\n'),
      language: 'javascript'
    });
  }
}

Might be problematic if another application part loads an incompatible AMD loader and a commonjs or unbundled version might be easier to integrate, but it works for me now.
The plus side with that approach is that all monaco sources and licenses are at a clear path in the output folder.

Still, it would be more usable in many projects if we could use it with webpack without the vs/loader.js. I tried to require the monaco-editor-core/vs/editor/editor.main which works until it tries to execute the define function with following error define cannot be used indirect.

just did as what @Matthias247 suggested, but got Module not found: edcore.main, full error log:
ERROR in ./app/~/monaco-editor/min/vs/editor/editor.main.js
 Module not found: Error: Cannot resolve 'file' or 'directory' /Users/egoist/dev/jslab/app/node_modules/monaco-editor/dev/vs/editor/edcore.main in /Users/egoist/dev/jslab/app/node_modules/monaco-editor/min/vs/editor
  @ ./app/~/monaco-editor/min/vs/editor/editor.main.js 85:0-2941 92:173-266 99:173-267 106:0-3357 107:0-244

ERROR in ./app/~/monaco-editor/dev/vs/editor/editor.main.js
Module not found: Error: Cannot resolve 'file' or 'directory' /Users/egoist/dev/jslab/app/node_modules/monaco-editor/dev/vs/editor/edcore.main in /Users/egoist/dev/jslab/app/node_modules/monaco-editor/dev/vs/editor
@ ./app/~/monaco-editor/dev/vs/editor/editor.main.js 83129:173-266 83136:173-267 83143:0-3357 83144:0-244

Version 0.5.3

Any update? It's basically unusable in angular2 projects as it is.

This is a major missing part :disappointed: would be really nice to get it working with webpack without hacking with CopyWebpackPlugin.

Tried to implement monaco using systemJS with jspm, which supports AMD modules.
Getting the following error on import:
(index):14 Error: (SystemJS) Cannot read property 'performance' of undefined
	TypeError: Cannot read property 'performance' of undefined
	    at AMDLoader (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/loader.js:1552:36)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/loader.js:1650:5)
	    at Object.eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/loader.js:2228:3)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/loader.js:2230:4)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/loader.js:2231:3)
	Evaluating<EMAIL_ADDRESS>	Evaluating<EMAIL_ADDRESS>	Evaluating http://localhost:14992/app/app.component.js
	Evaluating http://localhost:14992/app/main.js
	Error loading http://localhost:14992/app/main.js

On closer inspection it looks like it doesn't like global for _amdLoaderGlobal, so I set it to AMDLoader. Same thing with global being set for the NLSLoaderPlugin.
It then blows up in editor.main.js with the following error:
	TypeError: define is not a function
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/editor/editor.main.js:14:5)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/editor/editor.main.js:74765:6)
	    at Object.eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/editor/editor.main.js:75181:3)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/editor/editor.main.js:75183:4)
	    at eval (http://localhost:14992/jspm_packages/npm/monaco-editor@0.5.3/dev/vs/editor/editor.main.js:75184:3)
	Evaluating<EMAIL_ADDRESS>	Evaluating<EMAIL_ADDRESS>	Evaluating http://localhost:14992/app/app.component.js
	Evaluating http://localhost:14992/app/main.js
	Error loading http://localhost:14992/app/main.js

Setting the window require and define to the systemJS implementations of amdRequire and amdDefine doesn't help, but setting the define / require in the editor.main.js does.
At that point, it hits a monaco is undefined error.

thanks to @Matthias247 I got it working with angular rc5 with angular-cli: 1.0.0-beta.11-webpack.8
@fxck @waywaaard  my additions to @Matthias247  can be found here:
https://gist.github.com/chrisber/ef567098216319784c0596c5dac8e3aa

I have created a package named react-monaco-editor, it based on the approaches mentioned above (thanks to @Matthias247), hope it helps if someone uses React stack. Also hope it to be abandoned in the near future (after a better way appeared).

For anyone using TypeScript and React, here's the component I came up with:
/// <reference path="../node_modules/monaco-editor/monaco.d.ts" />

import * as React from 'react';

declare const require: any;

interface Props {
  value: string;
  language: string;
  onChange: (newValue: string) => any;
}

export default class MonacoEditor extends React.Component<Props, {}> {
  editor: monaco.editor.IStandaloneCodeEditor;

  render(): JSX.Element {
    return

;
  }

  componentDidMount() {
    // Monaco requires the AMD module loader to be present on the page. It is not yet
    // compatible with ES6 imports. Once that happens, we can get rid of this.
    // See https://github.com/Microsoft/monaco-editor/issues/18
    (window['require'])(['vs/editor/editor.main'], () => {
      this.editor = monaco.editor.create(this.refs['editor'] as HTMLDivElement, {
        value: this.props.value,
        language: this.props.language,
        lineNumbers: false,
      });

      this.editor.onDidChangeModelContent(event => {
        this.props.onChange(this.editor.getValue());
      });
    });
  }

  componentDidUpdate(prevProps: Props) {
    if (prevProps.value !== this.props.value && this.editor) {
      this.editor.setValue(this.props.value);
    }

    if (prevProps.language !== this.props.language) {
      throw new Error('<MonacoEditor> language cannot be changed.');
    }
  }
}

@danvk, @Matthias247: How are you working around the edcore.main and fs errors in vs/language/typescript/lib/typescriptServices.js? The approaches you've both mentioned above still fail mid-way for me.
Sorry if this is a silly question. Kind of confused though as I've tried essentially the same thing the 2 of you mentioned but with different results.

@bvaughn I had that error only when trying to use Webpack ProvidePlugin.
The other approach that I describe here which uses CopyWebpackPlugin and monacos AMD loader does not produce an error.

Hm. I was getting the error using their AMD loader and require.config (rather than CopyWebpackPlugin). I tried CopyWebpackPlugin at one point earlier but wasn't able to get it working.

@Matthias247 I took your example and nicely packaged it into an ugly npm package https://github.com/0plus1/ng2-monaco-editor, it's there for myself mainly and for the community, if anybody wishes to contribute please feel free!

Regarding @Matthias247 's example, I would like to add that using this angular2 seed, it's not necessary to do any symlinking or using webpack to copy files.
You can simply import from node_modules as shown below:
ngAfterViewInit() {
    var onGotAmdLoader = () => {
        // Load monaco
        (<any>window).require.config({ paths: { 'vs': 'node_modules/monaco-editor/min/vs' } });
        (<any>window).require(['vs/editor/editor.main'], () => {
            this.initMonaco();
        });
    };

    // Load AMD loader if necessary
    if (!(<any>window).require) {
        var loaderScript = document.createElement('script');
        loaderScript.type = 'text/javascript';
        loaderScript.src = 'node_modules/monaco-editor/min/vs/loader.js';
        loaderScript.addEventListener('load', onGotAmdLoader);
        document.body.appendChild(loaderScript);
    } else {
        onGotAmdLoader();
    }
}

@siovene thanks for that, tested it on angular-cli and it doesn't work :-(

Maybe the build script for this special project already copies the whole node_modules folder to the output. This would means monaco is in the correct place. Or it drops the main output file into the main folder of the project. However it's hard to tell what exactly it does since it's so big. In the general case you have to assure that monaco is available in the built  project.

Btw, I improved my approach since the last posting a little bit. I moved all monaco loading code into a seperate angular2 service component/class:
monacoeditorloader.ts:
declare const require: any;

export class MonacoEditorLoader {
  private _loaded = false;
  private _loadPromise: Promise<void>;

  constructor(
  ) {
    this._loadPromise = new Promise<void>(resolve => {
      // Fast path - monaco is already loaded
      if (typeof((<any>window).monaco) === 'object') {
        resolve();
        return;
      }

      var onGotAmdLoader = () => {
        // Load monaco
        (<any>window).require(['vs/editor/editor.main'], () => {
          this._loaded = true;
          resolve();
        });
      };

      // Load AMD loader if necessary
      if (!(<any>window).require) {
        var loaderScript = document.createElement('script');
        loaderScript.type = 'text/javascript';
        loaderScript.src = 'vs/loader.js';
        loaderScript.addEventListener('load', onGotAmdLoader);
        document.body.appendChild(loaderScript);
      } else {
        onGotAmdLoader();
      }
    });
  }

  get monacoLoaded() {
    return this._loaded;
  }

  // Returns promise that will be fulfilled when monaco is available
  waitForMonaco(): Promise<void> {
    return this._loadPromise;
  }
}

I expose that through an angular2 module, which declares this as a provider amongst some other common services:
@NgModule({
  declarations: [],
  imports: [
    BrowserModule,
    HttpModule,
  ],
  providers: [
    ...
    MonacoEditorLoader,
  ],
})
export class ServicesModule {
}

In all components that want to utilize monaco later on I get the loader through DI, wait for the load to complete and create monaco editors. The advantage of this approach is that loading is separated from utilizing Monaco and that it's easy to use Monaco in multiple components without big code duplication. The only drawback is that loading is still asynchronous - the editor won't be immediatly there after ngAfterViewInit. It's sometimes visible that the editor pops up later. But for me that's not a real problem.
@Component({
  selector: 'editor',
  directives: [COMMON_DIRECTIVES],
  template: `

  `,
})
export class Editor implements OnInit, AfterViewInit, OnDestroy {
  @ViewChild('editor') editorRef: ElementRef;

  constructor(
    private _monacoLoader: MonacoEditorLoader
  ) {
  }

  ngAfterViewInit() {
    // Wait until monaco editor is available
    this._monacoLoader.waitForMonaco().then(() => {
      if (this._disposed) return;
      this.initMonaco();
    });
  }

  initMonaco() {
    this._editor = monaco.editor.create(this.editorRef.nativeElement, {
      value: '',
      language: 'javascript'm
    });
  }
}

i think the html5 imports* is probably the most simple approach at the moment:

the server of monaco will need to enable http2 to get decent performance (based on experience).
html5 imports is a decent-enough module system. i was suprised when i discovered what one could do with it.
in Polymer, one would use a similar tool to bundle web components (think AMD modules), see https://github.com/Polymer/vulcanize. however, this is going to become obselete due to http2.
build process becomes much simpler.

all in all, everything becomes much simpler.
@alexandrudima, have you had a chance to look at this?

http://webcomponents.org/articles/introduction-to-html-imports/

I'm encountering similar problems when trying to use require.js and r.js. A normal build works locally, but trying to generate a single bundle with r.js yields errors of the form:
Tracing dependencies for: main
Error: ENOENT: no such file or directory, open '/home/mgodbolt/personal/dev/compiler-explorer/out/dist/ext/monaco-editor/dev/vs/editor/edcore.main.js'
In module tree:
    main
      hub
        editor
          colour
            monaco
              vs/editor/editor.main

and edcore.main.js is nowhere to be found in the npm package. Ideas welcome on how to fix this (would love to switch to monaco, but can't until I can deploy!)

any updates?

I'm using Electron with Webpack, and integrating Monaco is really a mess.
I cannot load Monaco by appending the loader.js script, as the loader won't recognize in which context it is, and I get an error with "exports".
And loading it by using Webpack's require directly gives me the same error about edcore.main.

@alexandrudima
From what I see in the gulpfile edcore.main is simply an alias to editor.main.
But I don't see any define of it.
https://github.com/Microsoft/monaco-editor/blob/master/gulpfile.js#L100
I don't really understand what this does, and I never used AMD modules before so it's a little bit obscure for me.
I really need to integrate Monaco in my setup with Webpack and Electron, and I'm pretty sure it's not much to modify to make it work.
Could you explain to us what this addPluginContribs function really does, and what really is edcore.main?
Monaco and VSCode are really beautiful projects, and it's demoralizing to see that we can not use it in our Webpack projects.

@kube I used the below based on what alexandru posted in another issue (which I seem to have misplaced).
index.html in an Electron / webpack project:

Also note that when running the project in Electron, you don't actually need webpack -- you can require all of your source directly into the browser. Hope this helps!

@cloverich

@kube that is the solution I used when I was using webpack. Can you share the your code, or a minimum setup with the issue?

@Matthias247 Hey, I'm interested in incorporating your findings into our project.  Is what you have here the latest version?  Also, I'm interested in seeing the custom functionality bit.  Thanks.

@icfantv Hey, yes, that's still my latest version. Unfortunately can't show more about the remaining code since it contains mostly proprietary features. But the idea is simply that the intermediate component which adds custom functionality waits for the basic monaco loader to be ready, calls Monaco APIs to add custom syntax highlighting, autocompletions, etc. and then dispatches a ready event itself (or completes a promise). The component which wants to use a Monaco editor in the end then waits for this ready event instead of the _monacoLoader.waitForMonaco() event. E.g. it could be _monacoWithExtensionsLoader.waitForMonaco().

@Matthias247 got it and looks easy enough.  Thanks again for posting this.

So i've managed to get it working with the Angular CLI.
In you angular-cli.json put this in the assets:
"assets": [
       "assets",
       "favicon.ico",
       {
         "glob": "**/*",
         "input": "../node_modules/monaco-editor/min/vs",
         "output": "./assets/monaco/vs/"
       }
],

This will serve the monaco folder in the assets folder. When building the application it will also copy the files to the dist/assets folder. Works great! 👍
Then use the code provided by @Matthias247 over here, but replace the 'loadPromise' in the monacoeditorloader.ts with the following:
this._loadPromise = new Promise<void>(resolve => {
            // Fast path - monaco is already loaded
            if (typeof ((<any>window).monaco) === 'object') {
                resolve();
                return;
            }

            const onGotAmdLoader = () => {
                // Load monaco
                (<any>window).require.config({ paths: { 'vs': '/assets/monaco/vs' } });
                (<any>window).require(['vs/editor/editor.main'], () => {
                    this._loaded = true;
                    resolve();
                });
            };

            // Load AMD loader if necessary
            if (!(<any>window).require) {
                const loaderScript = document.createElement('script');
                loaderScript.type = 'text/javascript';
                loaderScript.src = '/assets/monaco/vs/loader.js';
                loaderScript.addEventListener('load', onGotAmdLoader);
                document.body.appendChild(loaderScript);
            } else {
                onGotAmdLoader();
            }
        });

What a pity. No webpack support.

Hello everyone,
Thanks to @Matthias247. I created a simple library for Angular to make sure that Monaco editor is ready without using timeouts or then with Promises. I did not want to clutter my components with those functions. Please check it out.
Introducing 🎉🎉🎉 Angular Monaco Editor Loader 🎉🎉🎉
https://github.com/leolorenzoluis/xyz.MonacoEditorLoader
All I have to do now is

Hi there!!! Sean (from webpack). I'd love to discuss the possibility of shipping Monaco using the Harmony Module format (esm). What's the best medium to propose this?

@TheLarkInn
I'm not intimately familiar with webpack, and I've only tangentially followed the ES Harmony module proposal, but I am quite knowledgeable in AMD (having written our AMD loader, bundler, etc.). I can describe what we're doing and why we're doing it and hopefully we can use our collective brain power to come to a good solution.
Some of the requirements are probably quite general of any large software project, some of them are unique...
Basic considerations

the monaco-editor node module comes together by "stitching" together the monaco-editor-core node module and several monaco-* plugins (also distributed via npm) that add various language supports. Their location is described here. This makes it possible, by forking this repository (and tweaking the metadata.js root file), for someone to create a monaco-editor distribution which contains the html plugin, but not the json plugin, etc. Or someone can package a monaco-editor distribution with an additional plugin that they author.
for the purpose of better supporting webpack, we can change the monaco-* plugins shape more or less freely (changing them only impacts the monaco editor), so we don't need to think too deeply about them, except for the lazy loading point below.
the monaco-editor-core node module, (a language agnostic editor), gets shipped straight from VS Code's sources. We must maintain single source with VS Code, otherwise all the good work we're doing for the VS Code editor would probably never make it to the monaco editor.

VS Code is the editor's "home". The monaco-editor-core simply shims many services the editor code needs such that it can be hosted in a standalone manner. e.g. IProgressService, IMessageService, IKeybindingService, etc
we want to keep our CSS next to the code that needs it. e.g.

hover.ts requires `vs/css!./hover'
this indicates that the factory method of hover.ts should be invoked only after the CSS in hover.css has been loaded.

we want i18n to be painless for developers. e.g.

we import nls from vs/nls
to define a translatable string, we make a simple call in the source code to nls.localize where we define an identifier (that disappears at runtime) and the English value for the string. Sometimes, we can even provide more metadata with explanations for translators if we make the call with a different shape. e.g. : simple, with comments intended for translators

we have an entire translation pipeline set up for VS Code from which the Monaco Editor benefits. nls.localize calls can all be analyzed statically and strings to be translated are extracted. They then get pushed to a format Transifex likes and then translations can be pulled back from it and get converted to .json files in our repository.
when we compile with a "release" target in mind (i.e. not just for running out of sources), all the code that required vs/nls gets patched to signal the caller module it e.g. a require of vs/nls from vs/editor/contrib/hover/browser/hover.ts gets rewritten to vs/nls!vs/editor/contrib/hover/browser/hover, all the English strings are extracted to a separate file hover.nls.js and all the nls.localize calls are rewritten to pass in the numeric index of the string in a file, to give a nice array cost (O(1)) of using a localized string.
at bundle time, we start with vs/editor/editor.main and ship only the subset of modules that are needed (referenced) for the monaco editor.
nls: the vs/nls plugin participates in the bundling phase and concatenates all the nls strings in a single file, and consolidates dependencies. e.g. vs/nls!vs/editor/contrib/hover/browser/hover is defined as define('vs/nls!vs/editor/contrib/hover/browser/hover', ['vs/nls', 'vs/nls!vs/editor/editor.main']), function(nls, data) { return nls.create("vs/editor/contrib/hover/browser/hover", data); }); . so all of the nls dependencies end up redirecting to vs/nls!vs/editor/editor.main, and the plugin generates various nls.*.js bundles for the various languages we ship (e.g. German, Chinese, etc.)
css: the vs/css plugin also participates in the bundling phase and concatenates all the CSS, taking of course into consideration that the relative paths to images have changed and inlines all of the images below a certain size (we have lots of small svg icons).
the bundler does some simple transformations to reduce code size, such as eliminating duplicated TS helper definitions and hoisting up all the AMD module names such that they don't get repeated again and again and again.
finally, "because life", we shim our octicons usage since we want those in VS Code, but their size cost is not paying off for the monaco editor.

Requirements
Even after all of this stuff has happened and we have extracted the precise subset of source code, nls strings, CSS, and images that the monaco editor needs out of VS Code, there are still some special requirements we have.
We want to use web workers to have a never blocking UI. e.g. if you use the monaco diff editor, the diff is always computed in a web worker. if you use JS/TS/etc, the ASTs and analysis and heavy lifting of computing completions, etc. happens on a web worker.
We want to lazy load languages. e.g. if you instantiate an editor model with the language css, we want to dynamically load only the CSS specific code. i.e. on the main thread, we load the CSS colorizer and the CSS part of the plugin that registers the CSS language smarts provider; the CSS plugin makes use of some straight forward API to create a web worker and load its specific code in the new web worker. The basics of a web worker that can do buffer sync is at vs/base/worker/workerMain.js.
If, later, you instantiate an editor model with the language html, etc, the same happens for html.
Integrator burden

we try to hide most of this complexity to the point where an integrator "simply" needs to ship a bit-to-bit copy of the files we distribute to production, and the lazy loading of programming languages and the configurable loading of natural languages aspect brings in the runtime dependency towards an AMD loader.

If the integrator has their own AMD compliant loader (i.e. that supports plugins), we will run with that. Otherwise, integrators can use the AMD loader we supply at vs/loader.js.
e.g. a simple-case integrator can get away with:
require.config({ paths: { 'vs': '../path/to/vs/folder' } });
require(['vs/editor/editor.main'], function() { /* editor loaded here */ })

A fancier integrator that is concerned about the loading waterfall can load the editor synchronously by doing something like. e.g.:
<link rel="stylesheet" data-name="vs/editor/editor.main" href="path/to/vs/editor/editor.main.css">

An integrator that wants to load a different natural language can either load editor.main.nls.de.js or configure the nls plugin. e.g.
Conclusions
My problem is I'm not really sure what the requirement is here and what the desire is.
Do integrators want to bundle the monaco editor through their own webpack config

Do we then need to ship 1000s of files, some of them not needed (i.e. files only used in VS Code)
Do the integrators want to deal with patching our nls.localize calls and correlating those with translated strings and creating nls bundle files?
Do the integrators want to deal with concatenating our 100s of CSS files and inlining small svg icons?
Do the integrators want to deal with our N entry points: vs/editor/editor.main.js, vs/base/worker/workerMain.js, vs/basic-languages/src/XXXX.js, vs/languages/json/{jsonMode,jsonWorker}.js, do the integrators want to know that the TS/JS plugin consists of 3 files: a mode.js, a worker.js and typescriptServices.js that is loaded both on the main thread and in the worker -- it is loaded on the main thread for colorization purposes and on the worker thread for language services purposes.

Do integrators want to load the monaco editor with webpack

but... this should just work, right? since webpack supports loading AMD code.

I apologise if I'm missing the point, supporting the Harmony module format might be as easy as us replacing our calls to define('moduleId', ['req1', 'req2', ... ]) with module "moduleId" { import  X from 'req1' ... } and our lazy loading from require(['lazyCode'], function() { ... }) with Loader.load calls, but there still remains the challenge of what vs/css and vs/nls should map to. Shipping our code in such a shape would also mean the editor source code is not loadable in IE11 without a loader that ... loads the code via xhr and uses eval / regexes to discover those dependencies ?
I'm also happy to do more reading on the subject if you know of a good article explaining what's expected from us to be ES Harmony module compliant in what we ship. Or ... if you have any ideas, I'd love to hear them.

In CodeMirror we can bundle it with webpack by hacking a little of it's public overridable APIs, heres what we tried and succeed:
import {noop} from 'lodash';
import CodeMirror from 'codemirror/lib/codemirror';

import 'codemirror/mode/meta';
import 'codemirror/mode/brainfuck/brainfuck';
import 'codemirror/mode/clike/clike';
import 'codemirror/mode/cmake/cmake';
import 'codemirror/mode/coffeescript/coffeescript';
import 'codemirror/mode/commonlisp/commonlisp';
import 'codemirror/mode/css/css';
import 'codemirror/mode/d/d';
import 'codemirror/mode/diff/diff';
import 'codemirror/mode/eiffel/eiffel';
import 'codemirror/mode/fortran/fortran';
import 'codemirror/mode/gherkin/gherkin';
import 'codemirror/mode/go/go';
import 'codemirror/mode/groovy/groovy';
import 'codemirror/mode/htmlembedded/htmlembedded';
import 'codemirror/mode/htmlmixed/htmlmixed';
import 'codemirror/mode/idl/idl';
import 'codemirror/mode/jade/jade';
import 'codemirror/mode/javascript/javascript';
import 'codemirror/mode/jsx/jsx';
import 'codemirror/mode/julia/julia';
import 'codemirror/mode/lua/lua';
import 'codemirror/mode/markdown/markdown';
import 'codemirror/mode/mathematica/mathematica';
import 'codemirror/mode/mllike/mllike';
import 'codemirror/mode/nsis/nsis';
import 'codemirror/mode/perl/perl';
import 'codemirror/mode/php/php';
import 'codemirror/mode/powershell/powershell';
import 'codemirror/mode/properties/properties';
import 'codemirror/mode/protobuf/protobuf';
import 'codemirror/mode/puppet/puppet';
import 'codemirror/mode/python/python';
import 'codemirror/mode/q/q';
import 'codemirror/mode/rpm/rpm';
import 'codemirror/mode/rst/rst';
import 'codemirror/mode/ruby/ruby';
import 'codemirror/mode/rust/rust';
import 'codemirror/mode/sass/sass';
import 'codemirror/mode/scheme/scheme';
import 'codemirror/mode/shell/shell';
import 'codemirror/mode/smarty/smarty';
import 'codemirror/mode/soy/soy';
import 'codemirror/mode/sql/sql';
import 'codemirror/mode/stex/stex';
import 'codemirror/mode/swift/swift';
import 'codemirror/mode/tcl/tcl';
import 'codemirror/mode/toml/toml';
import 'codemirror/mode/troff/troff';
import 'codemirror/mode/ttcn-cfg/ttcn-cfg';
import 'codemirror/mode/vb/vb';
import 'codemirror/mode/vbscript/vbscript';
import 'codemirror/mode/verilog/verilog';
import 'codemirror/mode/xml/xml';
import 'codemirror/mode/yaml/yaml';

import 'codemirror/addon/search/search';
import 'codemirror/addon/search/searchcursor';
import 'codemirror/addon/search/jump-to-line';
import 'codemirror/addon/search/matchesonscrollbar';
import 'codemirror/addon/search/match-highlighter';
import 'codemirror/addon/scroll/annotatescrollbar';
import 'codemirror/addon/scroll/simplescrollbars';
import 'codemirror/addon/dialog/dialog';
import 'codemirror/addon/selection/active-line';
import 'codemirror/addon/display/fullscreen';
import 'codemirror/addon/display/autorefresh';
import 'codemirror/addon/edit/trailingspace';
import 'codemirror/addon/mode/overlay';

import 'codemirror/lib/codemirror.css';
import 'codemirror/addon/dialog/dialog.css';

import './CodeMirror.global.less';

CodeMirror.requireMode = noop;
CodeMirror.autoLoadMode = noop;

export default CodeMirror;

These code is simple:

importing CodeMirror from npm packages
importing modes (language syntax highlighting) and addons (plugins) on demand
Override the requireMode and autoLoadMode static methods to noop, this disables the "loader" shipped by CodeMirror (which originally supports both CJS and AMD)

After override requireMode and autoLoadMode it's not possible to load language modes or addons on demand, so when dynamic load is required, we can just leave these two methods and do a copy/paste work, in this way CodeMirror works similar to how current monaco-editor behaves
Bundle with webpack is very useful for applications in a predictable and fast network environment

has anyone tried to auto convert it with tools like amd-to-es6?

@alexandrudima already had a thorough check list above. I played with webpack these few days and synced with @TheLarkInn , here are my findings, correct me if I made anything wrong.
Integrate with Webpack: Load
There are already a few solutions above about how to make Monaco Editor work with Webpack, the key point is

Ask webpack not to resolve Monaco related modules, e.g. vs/editor/editor.main.
Copy Monaco bits to output folder, you can use CopyWebpackPlugin.
Use a amd loader to load Monaco Editor and corresponding plugins.

We can even put amd loader into a closure to avoid conflict with other module system.
Integrate with Webpack: Bundle
Ppl may want to bundle Monaco editor with Webpack. Webpack will try to resolve modules when bundling Monaco modules, to make it compatible:

For vs/css!, we can use CSS loader to bundle CSS the same way as our AMD CSS Plugin. One catch here is we don't put file extension to CSS file when referencing, we can use NormalModuleReplacementPlugin to mitigate this problem.
For vs/nls!, we need to write a custom loader for NLS.

However, if we directly use webpack to bundle our npm package, we'll see following errors/warnings like below

Cannot resolve module vs/editor/edcore.main
define cannot be used indirect
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
Critical dependency: the request of a dependency is an expression

This is due to Webpack's module resolution mechanism. It tries to resolve modules statically so code like
var module = languageDefinitions[languageId].module;
return new _monaco.Promise(function (c, e, p) {
      require([module], function (mod) {
      }, e);
});

won't work as webpack doesn't know to evaluate module. This explains

Cannot resolve module vs/editor/edcore.main

we didn't use string literal directly when defining vs/editor/edcore.main in the bundled main entry editor.main.js, it confuses webpack. Workarounds are using string literal when bunding Monaco or shipping all files and then webpack can resolve modules by file paths/names.

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
Critical dependency: the request of a dependency is an expression

If those modules already exist in the component, we can leverage https://webpack.github.io/docs/context.html#dynamic-requires to solve the problem. We still use above code snippet as example
https://github.com/Microsoft/monaco-languages/blob/master/src/monaco.contribution.ts#L26
var module = languageDefinitions[languageId].module;
return new _monaco.Promise(function (c, e, p) {
      require([module], function (mod) {
      }, e);
});

As we know all language modules are in the same folder, so changing it to
var module = languageDefinitions[languageId].module;
return new _monaco.Promise(function (c, e, p) {
      require(['./' + module], function (mod) {
      }, e);
});

and then webpack will create a context module, this module contains references to all modules in that directory that matches a certain pattern.
There are a few other places (in the core and all builtin extensions) that we need to apply dynamic require.
Open Items
I can already bundle Monaco-Editor-Core + Basic Languages with Webpack but didn't succeed bundling all extensions. There are still several questions I don't have answer yet

Can we define multiple AMD modules in a single file and tell Webpack to resolve modules from that file?
Is it possible to tell webpack skip some require function all when webpack_require fails? There are some places that the modules we try to require are real dynamic (they don't exist yet when bundling), falling back to a simple require and then the module can be loaded correctly on runtime. https://github.com/webpack/webpack/issues/4545

If above two problems are solved someway, then the left work is tweaking core and extensions, creating entry points for both main thread and web worker.

Can we define multiple AMD modules in a single file and tell Webpack to resolve modules from that file?

I'm not sure what you mean, could you provide an example.

Is it possible to tell webpack skip some require function all when webpack_require fails? There are some places that the modules we try to require are real dynamic (they don't exist yet when bundling), falling back to a simple require and then the module can be loaded correctly on runtime. webpack/webpack#4545

Yes, you can! Just as the NormalModuleReplacement allows one to "hijack and modify" the request from a NormalModule, the ContextReplacementPlugin will allow one to define a custom context, or filter an existing ContextModule request. You can find more information in this thread.

@TheLarkInn thanks for the answer of require fallback. About my first question, it's about resolving modules in bundled files. Let's say I have a bundled file (which might be from node modules), it contains several modules
a.js
define('b', [], function () {
}

define('a', ['./b'], function () {
}

and we try to reference these two modules in entry file index.js.
define('index', ['./a', 'b'], function () {
}

a is accessible as the file a.js is in the correct folder. While webpack resolving module a, as module b is in the same file and already defined, webpack knows how to resolve a's dependencies.
My question is, is there any way to reference module b in entry files (index.js)? Moreover how can we require module a and b at runtime since webpack bundles them and probably replace the module name with absolute path.

is there any way to reference module b in entry files (index.js)?

As webpack ks a module bundler, there is no separated module in a bundle by default, you can make modules accessible by exporting them in your entry, or to configure webpack to export some modules, in both solutions the exports must be explicitly defined

how can we require module a and b at runtime

Webpack can bundle a CommonJS/AMD library so you can reference the module using CommonJS require or an AMD loader, but your code is probably:
define('myApp', ['monaco'], function (monaco) {
    const a = monaco.a;
    const b = monaco.b;

    // ...
});

I hope I'm not noising this thread up, but it has by far been the most useful resource in getting monaco working with my setup. I'm utilizing Monaco in an electron app and was having a little trouble with the loader @Matthias247 posted. Here is my working version based on a mashup of the above example and the official electron guidance:
declare const global: any
declare const require: any

const anySelf: any = self

const nodeRequire = global.require
let amdLoader

export default class MonacoEditorLoader {
    private _loaded = false
    private _loadPromise: Promise<void>

    // Returns promise that will be fulfilled when monaco is available
    waitForMonaco(): Promise<void> {
        if (this._loadPromise) {
            return this._loadPromise
        }
        this._loadPromise = new Promise<void>(resolve => {
            if (typeof((<any>window).monaco) === 'object') {
                resolve()
                return
            }

            var onGotAmdLoader = () => {
                amdLoader = global.require
                global.require = nodeRequire

                anySelf.module = undefined
                anySelf.process.browser = true

                amdLoader(['vs/editor/editor.main'], () => {
                    this._loaded = true
                    resolve()
                })
            }

            let loaderScript = document.createElement('script')
            loaderScript.type = 'text/javascript'
            loaderScript.src = 'vs/loader.js'
            loaderScript.addEventListener('load', onGotAmdLoader)
            document.body.appendChild(loaderScript)
        })
        return this._loadPromise
    }
}

I have copied vs into my build output directory to make it work.
It would be great if we could import and have everything JustWork™. My mind wandered to (BR)ACE and CodeMirror at first when hitting the initial blocks, but stuck with it because how much I love vscode and TypeScript. To live its life to the fullest!!! outside vscode it may need to meet developer's modern bundling/importing/building expectations for low friction adoption. Not sure if that means vscode needs to dogfood it as an external yet internal package or what, but the project appears to be sufficiently complex enough I'll leave that to the experts ;)

@TheLarkInn, looking forward for your implementation for webpack.
Let me know if I can do something to help on accelerating the development of that since now I am blocked due this issue.

I just came across this one here: https://www.npmjs.com/package/monaco-loader
Haven't tested it myself but maybe someone finds it helpful.

we use require.js to bundle our application, I have tried various ways of including the minified editor-main.js file using require - and it does correctly get bundled, even executed, but monaco is left undefined - is it true that you can use require.js somehow to load monaco?
apologies if I should start a different issue.

Benefit of using standard module loading convention in your code allowes for moving all loading/bundling logic to be placed outside of your code. That is - in bundler / loader config.
All popular loaders handle (via plugins) things like importing css, translation, lazy loading of.code and bundling / code splitting.
Monaco is great piece of software and there is lot potential for it, especially when used as part of specialosed software.
The goal is not only to make it easy to just drop in but also to make those things configurable for integrator who.needs custom.stuff. Webpack i perfect for that, making your code agnostic of eay it its.build and consumed. Everything is just a module. Some are sync,.some asyc, some are css or strings. Code.desnwt care. Loader.does. Thats why its important for people i guess.
Any progress on this.btw?' :-)

@rebornix @TheLarkInn Sorry for the ping, but is this something that will come in a near future?
It seems the idea was abandoned.

Where can one find details on loader and i18n stuff. Maybe we could work on getting plugins for webpack so that integrator can decide which modules are bundled and which are lazy loaded, but all with their (integrators) own bundling system.
I Guess the main issue here is that i have 2 loaders now:
1- webpack - witch i have full control  over (configuration)
2- monaco custom require which i cannot configure
also lazy loading, assets and internationalization loading logic is duplicated then.

@TheLarkInn  - is there maybe an option to "capture" calls to require in loaded modules and put in there custom logic? Especially for async requires or dynamic ones like monaco uses. Sorry for bother, but Can't find it in webpack docs.

@alexandrudima @rebornix @TheLarkInn I decided to have a crack at this over the weekend seeing as there doesn't seem to have been much progress on this issue lately.
TL;DR: I've made a proof of concept that uses Webpack to successfully compile the editor/plugins/CSS/etc into a single massive UMD script with no dependencies (published as @timkendrick/monaco-editor). It inlines CSS and remote worker scripts into the client-side bundle, and if you're feeling adventurous you can create a custom build using the Webpack loader I wrote. In short: it's totally possible to bundle Monaco via Webpack without any upstream changes.
In-depth technical details:
While this method seems to work fine, it uses a fairly elaborate webpack setup internally and I'm by no means suggesting that any of it is remotely sane. I'll try and explain the approaches I explored and suggest potential alternative avenues as I go along.
It was a bit of an ordeal trying to get this working: most of the time went into writing a custom Webpack loader (@timkendrick/monaco-editor-loader), which wraps the AMD modules with an injected RequireJS shim that gets executed at runtime and stitches all the modules together, taking into account the various extensions you've loaded etc. Ideally you'd just be able to run it through webpack and have done with it, or failing that I would have preferred to at least use something off-the-shelf like Almond, but the CSS and web worker parts of the Monaco code rely on require.toUrl() which isn't supported by Webpack or Almond, so I ended up writing my own custom shim. This started off as a few lines, but kept growing as more features were needed - looking back now it might have been better to investigate adding toUrl() behavior to Almond or something. It's several years since I've used RequireJS and the API docs are pretty vague, so I'm not super-confident that my loader is 100% compatible with the Monaco loader.js, but I basically just kept adding features till everything worked… it seems to get it all done without any problems though.
A nice benefit of going down the webpack route is that it gives you a lot more control than RequireJS over how you want to bundle your assets. As well as supporting async asset loading via baseUrl, my loader allows the user to choose to inline specific assets (e.g. editor.main.css, workerMain.js etc) into the main bundle, so that you don't need to serve these separately. Any CSS assets you specify will be inlined as data: URIs and any worker scripts will be inlined as blob: URIs (and loaded via URL.createObjectURL(blob)). This went surprisingly smoothly. Somewhat trickier was the fact that workerMain.js contains its own inbuilt version of the AMD loader, which asynchronously loads in any remote plugin worker scripts from within the worker process. Obviously we don't want this behaviour if we've already downloaded the remote scripts in the main bundle, so instead you need to inject them into the worker script through some other means. I ended up writing another webpack loader that mocks the importScripts() function exposed to the bundled worker script (in this case, workerMain.js), inlining the additional bundled remote scripts as part of the main worker script blob (which itself is inlined into the main bundle), thereby allowing you to combine all the additional remote worker scripts into the same local bundle, along with the main JS and CSS. If you choose not to bundle some or all of the assets, it'll fall back to the default behavior of loading them from the baseUrl (both in the main process and in the worker process).
Bearing all this in mind, If I were to do this again I imagine a much cleaner overall approach would be to run Webpack on the source TypeScript files directly. This isn't possible as it stands, seeing as Monaco relies on the additional AMD require() properties that aren't present on the node/webpack require() function, so Webpack will complain about being used dynamically (as far as I can gather, in Webpack require() operates more like a keyword than an object), so anything that relies on the extra AMD stuff will cause the build to break. Perhaps the least dirty approach would be to apply some kind of an AST transformation to all the Monaco source files at compile time, rewriting require.toUrl() calls to inline the actual resolved path instead? I feel like it's either that, or monkey-patch Webpack's require() somehow while still maintaining the usual Webpack require behaviour (not sure if that's even possible). There's also the issue of the vs/css!... and vs/nls!... plugin paths, but I suspect these would be pretty simple to solve via style-loader, and maybe some kind of custom i18n loader, I haven't really looked into it. As far as I'm aware though, assuming you set up a vs path resolver alias and equivalent loaders for the vs/css and vs/nls plugins, the only real impediment to using Monaco directly within Webpack is the use of require.toUrl/require.config etc., so if you can get around this it should be plain sailing.
Anyway, this was just an experiment, so I wouldn't recommend using my package in production: I haven't looked into browser compatibility / proper sourcemapping etc., and I'm not planning to maintain it, hence the @timkendrick/ prefixes) – but at least it proves it's possible. Hopefully this will be a useful starting point if others want to pick it up from here.
Give me a shout if you want more details on anything, I'm happy to help!

@timkendrick Thanks for this awesome write-up.
I would love to see the possibility of having all of Monaco/code bundled with webpack. For one, webpack's ability to bundle electron apps typically result in over 40% start time increase (so theres a legit win there). This would also let one convert most of the existing modules to be ESM.
One of my concerns is that there is a set of dynamic nature that Monaco relies on for loading plugins and services. Because webpack is a static build tool, there would have to be some separation between the core vscode functionality, and the extension system and providers, etc.
externals[vscode-extension-runtime: ?] => dynamicExtentionProvider
[vscode core code: esm]

This is kind of off the cuff and not well thought out at the moment, but I think there's a lot of ROI (build perf, general Monaco adoption, code launch and runtime perf), that could be gained from the transition.

@TheLarkInn yep totally agree – my runtime AMD-style shim was just a hack to get it working, I'd much prefer if it were 100% webpack.
As for the plugin-loading system, I've been facing the same problem in a pluggable side-project I'm working on – I've ended up with the core bundle exposing a global registerPlugin() style method on the window object, which each of the extension bundles calls at runtime when they start up (this works fine, but feels a bit like it's not making the best use of the bundler).
I might be misunderstanding what you're saying, but, isn't Monaco already essentially performing this same process via the global monaco api (see snippet)? If that's the case then I can't imagine how webpack would pose any problems here…
https://github.com/Microsoft/monaco-typescript/blob/fd172013f77fa599e03a1c17b79aab62637569fa/src/monaco.contribution.ts#L194-L222

Not sure if this helps, but it's also possible to use dynamic import() with webpack, which works well with TypeScript too.
In general, I think the best way is to have Monaco just use ES6 imports everywhere and the consumers can decide whether they want to bundle everything, let webpack figure out good chunks to load async or to transpile everything to AMD.

@TheLarkInn I had a chance to take another look at this over the Christmas break, and I've managed to get Monaco compiling entirely via webpack from the original TypeScript source files, with full source map support. It's a lot cleaner than my previous attempt, but there are still a few hacks and workarounds to get everything playing nicely together.
TL;DR: head to the @timkendrick/monaco-editor npm package if you want to grab a batteries-included equivalent of the official monaco-editor package (includes a standalone build containing everything inlined into a single JS file, as well as a build that consists of separate JS, CSS and worker JS files).
How it works

Webpack seems to have trouble loading pre-built VS Code UMD bundles, so I've had to pull in all the additional libraries as Git submodules and rebuild all the extensions from source as well

The webpack config defines aliases for all the bundled VS Code modules (vs, vs/basic-languages etc) so that imports are wired up correctly

Some of the modules use a runtime require() call to load additional modules; the webpack config defines individual contexts for each of these modules to effectively inline a predetermined set of additional modules

The main entry point (editor.main.ts) is run through my custom @timkendrick/monaco-editor-loader webpack loader, which bundles up the main entry point script along with the extension entry point scripts, plus the entry points for the additional worker scripts

All the TypeScript source files are run through ts-loader with the VS Code tsconfig.json settings plus a couple of additional overrides - notably module: "commonjs", rather than module: "amd" ("es6" seems to present problems…)

Once they have been transpiled to JS, the source files are run through a couple of custom Babel transforms (defined in @timkendrick/babel-preset-vscode), which a) rewrite the AMD-style require() calls to CommonJS style, and b) convert any vs/css!foo imports to foo.css

Any CSS imports are siphoned off by the style-loader / ExtractTextWebpackPlugin and handled via webpack

Worker scripts are either bundled into the main output file as blob: URLs or emitted as separate files and loaded by the browser (custom webpack loaders are used to implement both of these mechanisms)

I haven't looked into supporting the vs/nls stuff correctly; the default language seems to work fine out-of-the-box but I suspect that adding proper i18n support would entail writing another fairly simple custom loader

The webpack setup currently requires webpack 4.x due to a bugfix that I submitted for an issue that was breaking the webpack 3 build

All in all, this is still a pretty complex webpack setup but it feels a lot more robust than my previous attempt, and as predicted, startup performance is much better. To me, this approach feels stable enough to use in an actual project.
I'd say based on this experiment that if the VS Code team felt that webpack compatibility was a desirable goal for the Monaco editor then it probably wouldn't take long to convert the codebase - there are a few dynamic require() call expressions that could be rewritten statically to avoid the need for webpack context plugins, and you'd need to use webpack loaders as a replacement for the AMD-dependent require.toUrl() runtime worker loading and for the vs/nls stuff, but apart from that it should all be pretty trivial. I haven't had much experience with webpack's code splitting, but I imagine this could be very handy if there was a need for a minimal core and async extension loading.
This was all done as a proof-of-concept so I can't guarantee that I'll be able to maintain these npm packages. If anyone feels like investigating what would need to be done to adapt the main VS Code codebase for webpack, I'd recommend looking at timkendrick/monaco-editor/webpack/createConfig.js to see how I worked around the various edge cases, and timkendrick/monaco-editor-loader/lib/loaders/monaco.js to see how it compiles the main entry point and bundles the workers.
Let me know if there's any more info I can provide on this!

Having this same problem. Our devtool option is set to inline-cheap-module-source-map.
Disabling UglifyJsPlugin does the trick, build passes. Funnily enough, so does setting devtool to eval.
Even funnier, unsetting devtool does not fix the problem. What?!

Thank you for your patience! :heart:

I am happy to let you know that we have just published v0.11.0, which is the first release to include the editor packaged in an ESM format under the esm folder. This pretty much means that the editor can be consumed as simple as:
import * as monaco from 'monaco-editor';

There are 2 complete samples of using the editor with webpack that I have put together:

1. "Basic"
Full working example here.
The integration burden consists of:

You must package web workers. See webpack.config.js
You must let the runtime know where you have packaged those web workers. See index.js
You must ignore require() calls in typescriptServices.js when packaging. See webpack.config.js

2. "Picky"
Full working example here.
Same integration burden as above, but this example loads only the core of the editor, the find widget, the python colorization and nothing else! See index.js. This would allow you to pick which editor features you want in order to get a smaller bundle size.

OMG! WOW! This is awesome! I'll be sure to try this out and provide feedback.

Hello and nice work!
I've been trying to get this to work with webpack today. I've come as far so that I can see the editor, but I get a lot of console errors:

(I especially like the "window not found" error ;)
Anyways.
I mainly wonder three thing:

What does self point to in self.MonacoEnvironment? I don't see any references to self and when I've been poking around in the sources it seems like it should be pointing to window- is that correct?

The workers in MonacoEnvironment object points to ./some.worker.js. Would it be just as fine to link to something like window.location.href + 'editor.worker.js'?

Is it important that the webpack config keeps the workers in seperate files rather than bundling all files to the same script?

Sorry if my questions are ridicolous, I'm still kinda new to this. :-)

@rockymontana did you add the webpack ignore plugin as specified in the final step of the "Basic" instructions above?

Yes I did.
entry: {
    app: './src/main.js',
    "editor.worker": './node_modules/monaco-editor/esm/vs/editor/editor.worker.js',
    "json.worker": './node_modules/monaco-editor/esm/vs/language/json/json.worker',
    "css.worker": './node_modules/monaco-editor/esm/vs/language/css/css.worker',
    "html.worker": './node_modules/monaco-editor/esm/vs/language/html/html.worker',
    "ts.worker": './node_modules/monaco-editor/esm/vs/language/typescript/ts.worker',
  },
  output: {
    path: config.build.assetsRoot,
    filename: '[name].js',
    publicPath: process.env.NODE_ENV === 'production'
      ? config.build.assetsPublicPath
      : config.dev.assetsPublicPath
  },
  plugins: [
    // Ignore require() calls in vs/language/typescript/lib/typescriptServices.js
    new webpack.IgnorePlugin(
      /^((fs)|(path)|(os)|(crypto)|(source-map-support))$/,
      /vs\/language\/typescript\/lib/
    )
  ],

Like that.

@rockymontana I'd add html-webpack-plugin and remove the default index.html with one that can be generated automatically to inject bundles for you.

The bundles are automatically injected. I see them in the markup. The rest of what you said was above my level of understanding 😭

@alexandrudima #40 #60 can now be closed also

@rockymontana
The challenge with the editor is that is creates web workers. Web workers have a completely different JS context, i.e. they are a fresh runtime. Also, web workers must behave differently than the source code in the UI thread. In the UI thread, our sources set up a monaco API which you can then use in order to create an editor. In the worker thread, our sources begin listening to messages and reacting to them correctly, according to a protocol which we define between the UI thread and the workers.
@timkendrick has managed to bundle the worker code as a blob in the bundle (probably similar to how CSS can be included as a blob), but my limited webpack experience prevented me from setting up something so cool :).
The error you are running into is IMHO a configuration error. I believe you are not defining the getWorkerUrl correctly in your application. i.e.:
self.MonacoEnvironment = {
	getWorkerUrl: function (moduleId, label) {
		if (label === 'json') {
			return './json.worker.bundle.js';
		}
		if (label === 'css') {
			return './css.worker.bundle.js';
		}
		if (label === 'html') {
			return './html.worker.bundle.js';
		}
		if (label === 'typescript' || label === 'javascript') {
			return './ts.worker.bundle.js';
		}
		return './editor.worker.bundle.js';
	}
}

The UI thread talks 100% the same way to the web workers, both in the AMD and the ESM case. In the AMD case, a web worker is loaded and then it gets specialized into a language worker via loadForeignModule. In the ESM case, we load a web worker which is directly specialized and then it will ignore the loadForeignModule message, as it has already that module loaded. So I believe there is a configuration problem in your code where the non-specialized worker is loaded for a language worker.
TL;DR put a breakpoint in your getWorkerUrl implementation and make sure you return the correct URL. Also, if you are creating your own web workers, be sure to also cover those in that method.

@TheLarkInn @timkendrick I am a webpack noob and this might be obvious :). When you get a chance, can you please take a look at the two examples and let me know if there are easier ways to set things up for webpack or if there are more things we can do in the way we distribute the ESM source code to make things easier.

wow thanks! that's great.
@TheLarkInn wouldn't it be possible to use dynamic imports to generate seperate bundles (files) for the workers?

@alexandrudima
Thanks a lot for the answer! I myself is quite the webpack noob so it's probably me doing something silly. The first thing I see is that you set self.MonacoEnvironment as where I set it to window.monacoEnvironment. The reason why I did that is so that I'm able to use the bundle where I need it instead of loading it globally even though I might not need it.
The second thing is that I try to use your config with my project which is a VueJS project.
I think I understand what has to be done, so I'll give it another shot and if I get lucky I'll see if I can explain what and why. Again - Thanks for the help!

@rockymontana I am trying to get it up in a vue app also if you want to collaborate.

Would require.context be of use here? It would force webpack to bundle all the workers without having to create separate entry points for each one, and should let you pull the paths out so you can load them into workers, if I'm not mistaken.

@mnpenner it turns out it's not quite as simple as that - see discussion on #759

@corbinu Absolutely! How would you like to do that?

@rockymontana Well at the moment my version is in a private Gitlab repo. I can give you access or try to open source it later today.

What’s your email?

@rockymontana If you do find a solution for vue, do share. I'm trying to set this up in a CodeSandBox vue environment but I'm having trouble figuring this out as well.

@moranje it might be because that Codesandbox does the bundling for you, which you can't choose the entry file (then no way to set up the worker). I'll sync with Ives and see if we can fix this problem or set up a Monaco editor template.

@rockymontana it is<EMAIL_ADDRESS>I will note mine is using the new vue-cli 3 beta

I really don't understand how I should configure the getWorkerUrl.
If you look at the following screenshots you'll see that I can retrieve the workers, and I can use the MonacoEnvironment from the console:

As you see in the screenshot above I can do this:
MonacoEnvironment.getWorkerUrl('', 'html')
which returns:
"http://<IP_ADDRESS>:8080/html.worker.js"
And the "proof" that it's reachable:

If I can configure this wrong, could you explain it to me like I'm a five year old, because I really don't see what's being misconfigured here.
Here's the webpack config again:
  entry: {
    vue: './src/main.js',
    app: './src/monaco.js',
    "editor.worker": './node_modules/monaco-editor/esm/vs/editor/editor.worker.js',
    "json.worker": './node_modules/monaco-editor/esm/vs/language/json/json.worker',
    "css.worker": './node_modules/monaco-editor/esm/vs/language/css/css.worker',
    "html.worker": './node_modules/monaco-editor/esm/vs/language/html/html.worker',
    "ts.worker": './node_modules/monaco-editor/esm/vs/language/typescript/ts.worker',
  },

And the generated markup from my index-file (at least the body parts):

Does that give you any ideas on why it's failing?

@meyer
I tried running the webpack example to see whether or not that would generate the workers as script tags, and just as you say, they actually don't. However - I can't really see anything that differs in the config, but then again - I suck pretty hard at webpack, so who am I to say hehe.
However - I checked the debugger dev tool tab and I can see that ts.worker.js is defined as a worker there, so I guess the browser can figure out that it's a worker even though it's a script tag.
¯_(ツ)_/¯

@rebornix @CompuIves thanks, that'll be great

I opensourced why I have so far here. It is a bit of a mess but everybody feel free to make experimental PRs or I am happy to add people as developers. I will move it to github as soon as I have time to clean it up and write a readme.
https://gitlab.com/corbinu/monaco-editor/

@corbinu Can I recommend that for specific changes you break them up and submit PR's to the source? This can help ensure that changes are tracked and understood and the Diff's can be reviewed etc.

And have issues that tie to said PR's it would be nice to have people discussion implementation details and whatnot in a shared context like a code review (even if it doesn't get merged, it still helps identify all the things that have to be cleaned up for this to work really well!)

@timkendrick has created a webpack plugin that hides all of this config away in PR #767 , and adds cool options to be able to pick whichever languages you want to use, or whichever features you want to use.
I will create a new editor release with this plugin shortly, and I hope that will simplify things tremendously.


[add] final additions

добавил тесты, запросы к бэкенду при регистрации

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 76.47059% with 12 lines in your changes missing coverage. Please review.

Project coverage is 94.50%. Comparing base (533d753) to head (11888db).
Report is 4 commits behind head on main.

Files with missing lines
Patch %
Lines

...nts/src/pages/register/components/Confirmation.tsx
60.00%
7 Missing and 1 partial :warning:

...e-accounts/src/pages/register/components/Email.tsx
63.63%
4 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

:exclamation:  There is a different number of reports uploaded between BASE (533d753) and HEAD (11888db). Click for more details.
HEAD has 1 upload less than BASE

Flag
BASE (533d753)
HEAD (11888db)

backend
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##              main      #70      +/-   ##
===========================================
- Coverage   100.00%   94.50%   -5.50%
===========================================
  Files           26       48      +22
  Lines          437      855     +418
  Branches        43      118      +75
===========================================
+ Hits           437      808     +371
- Misses           0       37      +37
- Partials         0       10      +10

Flag
Coverage Δ

backend
?

frontend
94.50% <76.47%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Simplify dev setup with npm

npm was already a requirement, so this just makes things easier for
anyone who wants to help.

Looks great! Thanks very much :)
Does this fix #49?

@tjvr It certainly helps towards 49, but I haven't tested it as an npm module. I could try if you want.


Enable discussions

Hello,
I know this isn't an issue but I didn't know where to put it. There are a few things I'd like to discuss:

Nested tables, and morerows/morecols support
Wiki-like index as an option, I find myself adding this to a lot of my conf.py

def rst_file_transform(docname: str) -> str:
    docname = "Home" if docname == "index" else docname
    return f"{docname}.rst"

def rst_link_transform(docname: str) -> str:
    return "Home" if docname == "index" else docname

_Sidebar option would also be really nice
Document names as titles so it looks nicer on some wikis

But apart from tables, all the others are opinionated so it may be good to discuss. So would it be possible to enable discussions?

Hi @jack-burridge-cfh, thanks for the suggestions. Support for nested markup would certainly be great, but I've found that this is rather error-prone, while I'm not using it very often. I gladly accept pull request that tries to improve the situation, but request that they are associated with a few tests to ensure they keep working. Sorry for not being able to promise more than that at this point.
As for the wiki-like naming, I'm a bit cautious to move too much logic to restbuilder. Application-logic like naming of documents seem appropriate in conf.py, but if you have a suggestion to make restbuilder more flexible (perhaps a mapping table for document titles <-> file names?), which reduces the effort you have to spend, I will consider it.
As for the last two suggestions, at this moment I can only promise to look into pull requests, but perhaps a bit more explanation is in order, before we add too much code to restbuilder which is only applicable to wiki output.

@macfreek I helped write the initial tests so willing to add more 😁 very much a fan of testing! (Different company different username)
Wiki-like index I'm sure I could write. Plus a push to wiki if you were to enable it (have docs that prove the consent kinda thing).
The last two require quite a bit I think, I'll try and come up with ways of doing it and raising PRs to review, see if it's not fattening the library too much.

Yes this is me! Just to assuage any doubts

Hi Jack, I should have recognized that! :) Happens if I don't pay close enough attention. My response was meant as an encoureagement to contribute, but also signifying that I may not have the time at the moment to work on it myself.
Since you are obviously using restbuilder for a longer time, submit meaningful contribution and communicate well, I've just given you write access to this repository, if you are willing to accept that invite.


Support Style Sheet file for Style of Alice Novel

Is your feature request related to a problem? Please describe. / あなたの提案する機能は何かの問題点に関連していますか?
I want to change design of Alice Novel.
Describe the solution you'd like / あなたの望む解決策の記述
Support CSS for change Alice Novel style.
Describe alternatives you've considered / 検討した代替案の記述

Change style from package.json file.

Additional context / 追加の内容
The CSS is user side(include .anproj file).

I want to prepare sample style for it on Alice Novel Samples.

when it change fonts (by style sheet), it have to reboot this application.

style sheet
https://learn.microsoft.com/en-us/dotnet/maui/user-interface/styles/css


need help mapping kernel at 0xC0000000 PAGE_FAULT (0xe)

First of all, I love this project and it helped me greatly in getting things going. I've made some changes in my project (mainly using grub instead of bootimage, just instead of make, etc) but the paging implementation is the same as edition-1. I've mainly followed edition 1 of blog_os.
When I try to remap the kernel to the higher half at 0xC0000000 i get a page fault in ActivePageTable::switch() with error code 0xE which is related to instruction fetch. This makes sense as the program counter is at 0x122f5e when the page fault occours. I think it is trying to proceed to execute the kernel using the physical addresses, but as the kernel is not identity mapped in this case it fails because the instruction fetch accesses unmapped memory.
My question is now do I have to manually reset the program counter after the kernel remap or can this be solved in a cleaner way? Resources on this would also be greatly appreciated if anyone knows something.
One idea I had was to call the paging setup from assembly and afterwards call kernel_main. I'll keep on trying things but if someone has an idea as to why this fails or how it could be fixed, I'd be glad to hear :D

Ah yes I do have error code 0x10, I wrote that wrong. Thank you for your insights. I'll try to map the kernel in the higher half using grub as that sounds easier although if I ever want to switch bootloaders the pre-kernel solution is probably cleaner.
If that doesn't work I'll try to do the pre-kernel solution. I've seen people mention that for this I have to adjust my linker script to split into higher and lower half, I didn't really understand that, but I think I'll figure it out.
Also I don't want to remap my heap.


[extractor/slideslive] Add support for embeds and slideshows

Adds support for SlidesLive embed URL format
Adds embed detection/extraction
Adds presentation slideshows as thumbnails and chapters

Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

I found the site has video slides too, which can be returned as a playlist. I can inline _extract_slides if that is better, but I thought this way would make things more readable


mvn install fails

Just run mvn install on a fresh pull
[ERROR] Failed to execute goal on project api: Could not resolve dependencies for project com.capitalone.dashboard:api:jar:3.0.2-SNAPSHOT: Could not find artifact com.capitalone.dashboard:core:jar:3.1.2-SNAPSHOT -> [Help 1]

java --version output:
java --version
openjdk 12.0.1 2019-04-16
OpenJDK Runtime Environment (build 12.0.1+12)
OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

mvn --version output:
mvn --version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T20:00:29+01:00)
Maven home: /usr/local/Cellar/maven/3.6.1/libexec
Java version: 12.0.1, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"

@no1melman jdk 11 is not supported at the moment.

please try with jdk 10 or below

@rvema it failed with
mvn --version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T20:00:29+01:00)
Maven home: /usr/local/Cellar/maven/3.6.1/libexec
Java version: 10.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.5", arch: "x86_64", family: "mac"


Could not determine if the replica is available exception

Hi, I've noticed no active replicas on status page for eureka cluster consisting of 2 eureka servers. We use route53-based txt dns setup, both servers in different az.
All running replicas in unavailable-replicas list, though logs contains replication activity.

What effect does it have for eureka cluster?
Can it cause situations when cluster losts overriden registry data when new servers added?
Any help in finding reasons of such behaviour appreciated.
 I'm not sure if it will be easy to figure out what issue you might be running into given the age of the version. Are you able to upgrade to a more recent release?

@qiangdavidliu Correction, we currently use 1.1.151 version

Please advise, which version (1.2, 1.3) should we use to fix mentioned issue.

Minor versions of servers should still be compatible. We are running with 1.3.8 servers as of this moment.

So, @qiangdavidliu is this actually a bug or something? Can you explain please more about the issue and its impact to Eureka availability, reliability etc.?

@pparth from looking at your error log and comparing against source code, it looks like the status result you are seeing is due to an NPE in your StatusResource itself, not necessarily due to any actual system issues. Given that you are seeing replication logs, it's likely your servers are still connected. One way to check is to try to make a /v2/apps/ call to see what the registry data looks like.
As an aside regarding the NPE, are you using the provided war to deploy your server or customizing it? Using the provided artifacts there shouldn't be any NPEs.

Indeed, this has to do with the StatusResource and we do have a customised Eureka Service and do not use the original war. We were just wandering whether this error is not only about status and has a deeper root cause as we  have a replication issue. @drax68  please provide more info about this.

@qiangdavidliu we have reproducible test case, where changes in eureka cluster contents (addition/removal of eureka servers to/from txt dns records) causes loss of overriden data in registry on all eureka servers (overriden statuses, custom metadata). Is this something known, or will require separate issue to investigate?

@drax68 that is a known issue. status overrides for eureka at an instance level are scoped for the lifetime of a registration. So for example when you remove a server, a previously registering client to that server (which was overridden) will switch registration to a different server, and reset the override. We have explored a few different ways of dealing with internally but it has not come up as a priority. Typically internally we set overrides at an (EC2) ASG level, and that is guarded by AwsAsgUtil.java.

@qiangdavidliu

Unfortunately, we think this issue raises its ugly head not only in a manual/administrative cluster upgrade but also in a standard failure pattern where a client cannot communicate with a server instance due to a network issue (e.g. for us, the ELB in front of the instance, croaked). This led all clients registered to this instance to switch to another server instance, which is what expected from the highly available Eureka setup we have in place. However, everything went south, as all our clients register themselves as STARTING and then we switch them to UP through the REST API, as part of a deployment workflow process we have in place. So, we ended up with ALL these clients switching to STARTING and traffic stopped! There goes the highly available cluster! At any case, we thought that the STARTING status was in place exactly to support this kind of workflow process. What are we doing wrong then? That we change the status externally through the REST API? If we allowed the instance to change its status on its own, from STARTING to UP, is everything going to work ok? We can do that if this solves the issue, however, this does not feel right as we pretend that the instance knows when it is ok to receive traffic when this is definitely an external, deployment-driven decision.
Can you explain more what is "we set overrides at an (EC2) ASG level, and that is guarded by AwsAsgUtil.java"?

Hi @pparth
Can I clarify that your (client) applications register with STARTING only, and only transition to UP status via an external trigger (the REST call from the deployment workflow process mentioned)?
We use discovery's statuses slightly differently internally. Internally, we tie discovery statuses (STARTING, UP, DOWN) with our application healthchecks, and the state transitions between these statuses are automatically governed by the applications. For example, an application will register with STARTING, and at some point in time (e.g. Guice container initialized, or some known async warm-up process has completed), the application will automatically transition it's own status to UP. The healthcheck is also tied in to this (eurekaClient.registerHealthCheckHandler()) and is used to move between UP and DOWN programmatically.
The OUT_OF_SERVICE status is used as a special case override. Our deployment workflow has the ability to make PUT and DELETE rest calls to the eureka servers to set and remove OUT_OF_SERVICE override statuses (see https://github.com/Netflix/eureka/wiki/Eureka-REST-operations, I have updated the doc to reflect the DELETE option of removing overrides).
A slight clarification to my point earlier regarding instance-level overrides are scoped only for a registration lifecycle, if a client re-registration happens to a different eureka server (as is the case when the original target eureka server disappears, such as for re-deployment), this is not considered as a new registration lifecycle (as an explicit unregistration never happens), and as such overrides are preserved.
Regarding my comment on AwsAsgUtil, internally our most common form of overrides are applied at the (EC2) AutoScalingGroup level. We synchronized our ASG disables with eureka's OUT_OF_SERVICE status, and the logic for that is contained within AwsAsgUtil.

Got it.
Unfortunately, in our case, we maintain multiple Service types per machine in an ASG, so, we cannot link the ASG disables to a specific Service type Eureka status.
Regarding the status overrides, it seems that we are back to zero. According to you, the overrides should be preserved in our case. So, @drax68  please check again about our case and dig up more information about what exactly happened in our system.

Re-tested that case, it's reproducible:
Eureka server configuration
eureka.appinfo.replicate.interval = 15
eureka.client.refresh.interval = 15
eureka.client.registerWithEureka = true
eureka.datacenter = cloud
eureka.environment = env
eureka.eurekaServer.context = eureka/v2
eureka.eurekaServer.domainName = eureka.env.example.com
eureka.eurekaServer.port = 8010
eureka.lease.duration = 45
eureka.lease.renewalInterval = 15
eureka.name = eureka
eureka.peerEurekaStatusRefreshTimeIntervalMs = 15000
eureka.port = 8010
eureka.preferSameZone = false
eureka.region = us-west-1
eureka.remoteRegion.registryFetchIntervalInSeconds = 15
eureka.serviceEnabled = true
eureka.serviceUrl.us-west-1a = {{us-west-1a-eureka-instance}}/eureka/v2/
eureka.serviceUrl.us-west-1c = {{us-west-1c-eureka-instance}}/eureka/v2/
eureka.shouldUseDns = true
eureka.statusPageUrlPath = /eureka/status
eureka.us-west-1.availabilityZones = us-west-1a,us-west-1c
eureka.vipAddress = eureka.example.com

Eureka dns name txt.us-west-1.eureka.env.example.com resolves to TXT record
"txt.us-west-1a.eureka.env.example.com" "txt.us-west-1c.eureka.env.example.com"
txt.us-west-1a.eureka.env.example.com resolves to
"elb1"
txt.us-west-1c.eureka.env.example.com resolves to
"elb2"
Test case is:

Deploy new pair of eureka instances behind individual elb
Wait for initial sync (let's say existing eureka instances has <apps__hashcode>STARTING_17_UP_122_</apps__hashcode> and newly-created <apps__hashcode>UP_118_</apps__hashcode>)
Append new instances to az-specific txt records:
txt.us-west-1a.eureka.env.example.com resolves to
"elb1" "elb3"
txt.us-west-1c.eureka.env.example.com resolves to
"elb2" "elb4"
Logs contains:

Updating the serviceUrls as they seem to have changed from [elb1, elb2] to [elb1, elb2, elb3, elb4]
Updating the replica nodes as they seem to have changed from [elb1, elb2] to [elb1, elb2, elb3, elb4]

And after that many service entries expiring with:
DS: Registry: expired lease for SERVICENAME - i-foobar
Not all services expiring at that moment, only about 30% of registered services.
Other services registry data remain unchanged, and all overrides migrated to a new nodes.
As I understand, service completely de-registered on expiration.
What can be the source of this massive expiration on cluster contents changes?

@qiangdavidliu Can you take a look at our latest information regarding the issue please?

@pparth looking at your description, this could potentially be an issue due to the order of operation between bringing up the new servers, and adding their records to the txt record. When a new server comes up, it will do a one time sync with a recognized peer (in this case an existing server). However this is one time only, so by the time this peer becomes a live server (due to the addition of it to the master txt records), the data it contain may now exceed the expiration deadline, especially when clients switch to registering with it.
Can you try the following to see if it helps with your case:

Add one elb to the txt record first before bringing up the new server
Wait a little to make sure dns propagates
Bring up the new eureka server

Eureka clients and servers are able to handle "missing" servers in the cluster.

Thank you, @qiangdavidliu
That sequence helped with unexpected registry data expiration.

@drax68 glad to hear that this resolves your issue.

i don't know english


bug: unknown_type rule not used

Putting the following in playground:
REPORT zfoobar.

DATA lt_foo TYPE aaa VALUE 2.
lt_foo = 'aa'.

Does not fire unknown_type rule error on 'aaa'. Same behavior on my local machine.
Remember this used to fire an error back 6 months ago.

works as intended, it depends on the configuration,


[supermassive] Add deps to types task

@vejrj @freiksenet Can/should we check these artefacts in, instead of requiring them to be build before we can invoke some of the other tasks?


Please add a license file

I'd like to add this to awesome-zsh-plugins, but it doesn't have a license file.
Please add a license file - if you don't have one in mind,  I recommend using choosealicense.com to help choose an appropriate one.
Thanks!

Thanks for pointing that out, that was just an oversight. I fixed it and used the MIT license.


Openthread fix crypto psa import key

According to PSA specification in case of PSA_KEY_TYPE_ECC_KEY_PAIR
function psa_import_key takes private key from key pair as argument.
This commit adds extraction of Private key from ECDSA key pair.
Also removes not needed otPlatCryptoEcdsaGetPublicKey.

@canisLupus1313 why did you remove otPlatCryptoEcdsaGetPublicKey function? Now the binary links the weak implementation from crypto_platform.cpp from OpenThread, based on mbedTLS. It's OK if it's not used right now but the platform API requires that it be provided.

@Damian-Nordic otPlatCryptoEcdsaGetPublicKey from plain text key pair is not used anymore in Openthread. The weak implementation was left there to indicate for users that this functionality shouldn't be used. That was the first reason.
Secondly the implementation of the function was never correct (since we haven't used it nobody noticed), the problem with is that even thought the  PSA function takes parameters that suggest it should be a key pair it really takes private key.


Overhaul Engine documentation

Continuation of similar past efforts with the same goal of refreshing the documentation up a notch. See also https://github.com/godotengine/godot/pull/80282 which is somewhat related.
This is particularly prickly due of the sheer size. There's also a constant fear of possibly losing important information, or making use of incorrect technical terms. A lot of the time is spent reading the original documentation and looking at the source code, too.

Made the wording match how other classes are documented A LOT more closely;

Simplified some wording which may be seen as awkward to read;
Use the present simple over future tense when applicable (will return -> returns);
Turned some long-winded sentences into notes at the end (and viceversa);

Link to other methods and parameters more often;
Tweak and add slightly more examples all around;
Tweak the way some dictionary entries are described:

There was this odd extra spacing after every entry and its description
([code]founders[/code]           - Array of Strings, founder names).
I can only speculate that documentation in the past used a fixed font spacing, which not longer matters, as it is stripped in the online documentation and just looks odd in the built-in one.
Add "- " prefixes. This turns them into proper list elements in the online documentation.
Add trailing semicolons at the end of every element.

Methods
get_architecture_name

Add quotes around return values;
Further clarify note below.

I still do not like "you can use the fact that" but it does work, I suppose?
get_author_info

Shortened description considerably;

The previous description was oddly repetitive even though there was not much to describe. It's all in one paragraph now, at the cost of possibly being more difficult to translate(?).

get_copyright_info

Detail how the parts entry of the dictionaries is composed;

The previous description did not give much insight on the most important values this method returns.

get_frames_per_second

Slightly elaborate on the returned value;
- "Returns the frames per second of the running game." wow, thanks!

get_license_info

Detail returned key-values in the Dictionary.

get_main_loop

Detail what the main loop is;
Add note about the equivalent project setting.

get_singleton, has_singleton, get_singleton_list

Remove possibly outdated example(?);
- "e.g. GodotPayments." I can't even find anything concrete about it?
Add note about Autoloads, which are not the same concept.

get_version_info

Updated example to say 4.1.

I really do not like how this is described, but I don't know how to fix it right now.
get_write_movie_path

Link to the equivalent project setting.

is_editor_hint
I feel like way more could be said here, but I don't know how to fix it right now.
is_in_physics_frame

Add concrete example.

Properties
max_fps

Completely overhaul description;

max_physics_steps_per_frame
Probably more should be done about it but I don't know how right now.
physics_jitter_fix

Reordered description around.

physics_ticks_per_second
Probably more should be done about it but I don't know how right now.
print_error_messages
Probably more should be done about it but I don't know how right now.
time_scale

Completely overhaul description;
Add note about values below or equal to 0.

Feedback is very, very welcome. Especially right now. This class is huge and very technical.

Rebased after:

https://github.com/godotengine/godot/pull/86071

Would be nice for it to be looked at sooner than later.

Addressed the above feedback. Thank you very much.

Rebased and made a few more notable changes to read nicer, especially around get_version_info. Can we have this now by 4.3?

Thanks!


Fix confusing start command label

Removed extra comma
Remove command from the label since the command is logged
afterwards

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @fbiville, good find! Can you please rebase or merge the latest master branch so this is up to date and then push up your changes after running npm run build so the that index file is rebuilt? Then I'll be able to merge this 👍

@fbiville
Before you execute npm run build, first run npm run format i.e.
npm run format
npm run build

npm run format changes the source into one line:
    return execCommand(startCommand, false, `start server`)

otherwise this will trip us up when PR https://github.com/cypress-io/github-action/pull/766 is merged.

https://github.com/cypress-io/github-action/actions/workflows/example-webpack.yml is one of the simpler workflows which shows the issue in the log:
start server "npm start command "npm start"

After your fix is applied the log shows:
start server command "npm start"

So this is a nice improvement!

@fbiville
I see that you submitted this PR more than one year ago. If you are no longer interested in seeing it through then it would be great if you could reply. I would pick it up and put your suggestion into a new PR in that case.

@fbiville

In the process of checking this PR I actually did all the work necessary to bring it up to date, so instead of asking you to repeat the work, I have opened a new PR https://github.com/cypress-io/github-action/pull/785 which credits you with having provided the solution and is ready to merge as a fix for the current version.

Thanks @MikeMcC399. I'll close this one down so we can move ahead.

Was in vacation last week, great to see the fix is happening in some form :)

@fbiville
Thanks for getting back to us! I expect that your fix will soon be merged.

@fbiville

PR #785 is merged and you now have Contributor showing against your name 💪🏻 as recognition for your submission.


Support Resource Discovery building block scalability to millions of records in eoAPI

@j08lue Can we collect some recommendations (e.g., for parameters, such as hydration, min/max parameters for db connections from stac-fastapi, item table partitioning, postgres database tuning parameters) and document them? I think this would be a very good start of this work item.


@ operator?

https://stackoverflow.com/questions/60080997/pytorch-porting-operator
Is there interest to add this?
var rotMat = xmat @ ymat @ zmat

'@' is not a binary operator in C#. How would that work?


Database Schema Task

Closing this PR as no pull requests should go directly to main. Please direct all pull requests to dev instead. Also, ensure to follow the Conventional Commits guide next time for your commit messages. Thanks!

@destinedcodes don't close people's PR, just leave a comment. This issue can easily be resolved by asking the person to change the target. You need not close the PR.

@davideshett point your PR to dev not main

Thanks Boss for the corrections.

@davideshett here is your check list

Go through all my review comments above and effect the requested changes
Move all Repository implementation to Hng.Infrastructure project.
Create a SeederService in Hng.Infrastructure project and implement the seeding there don't use a static method. Also, seeding should only happen once, when there's no data in those tables.
Move the Automapper profile to infrastructure under a folder called Mappers not Helper.
All Dtos and API logic should live in Hng.Application project as they are endpoint/application level concerns.

@davideshett include a description on how to test this.


libXslt: fails to build

@cemkeylan
kiss b libXslt
grep: /usr/lib/libintl.la: No such file or directory
sed: /usr/lib/libintl.la: No such file or directory
libtool:   error: '/usr/lib/libintl.la' is not a valid libtool archive
make[2]: *** [Makefile:499: libexslt.la] Error 1
make[2]: Leaving directory '/home/eudaldgr/.cache/kiss/build-2496/libXslt/libexslt'
make[1]: *** [Makefile:615: all-recursive] Error 1
make[1]: Leaving directory '/home/eudaldgr/.cache/kiss/build-2496/libXslt'
make: *** [Makefile:441: all] Error 2
-> libXslt Build failed

Complete log

That's weird, I don't have /usr/lib/libintl.la on my system, yet I don't have build issues.
It might be that one of your libraries are broken, because of an update, or removal of a package. Try to reinstall removed packages and rebuild the package.
I will get to this in a few hours, sorry for the delay.

Okay, libintl.a is a gettext library. If you previosly installed it, that's why. I think that you may need to rebuild libtool, because it may be the issue here.

Also libXslt links itself to these packages if they exist,

libgcrypt
libgpg-error
xz
zlib

So you may want to check them as well

yeah, i know it's something related the gettext package, but the thing is that after remove it, i rebuild all my installed packages and the problem persists

You can try something like this.
for lib in /usr/lib/*.so; do
    ldd $lib 2>/dev/null | grep -q libintl || continue
    printf '%s: depends on libintl\n' "$lib"
done

There is no output for this.

Since libintl doesn't exist and (iirc) ldd will throw an error to stderr. Perhaps you need to do 2>&1 instead of 2>/dev/null.

Okay, then try
for lib in /usr/lib/*.so; do ldd $lib >/dev/null ; done

This will output all errors on your libraries

Output

I am unsure about this situation. I would advise rebuilding libxml2 and binutils, but I honestly don't know.

I don't know why but when i packaged surf it was builded, the problem was happened when i'm trying to build vimb, and now i don't want it, but i think is solved and don't know why.

This is an issue with your system and not the libXslt package. :+1: