profile
viewpoint

bolinfest/chickenfoot 61

Firefox extension to enable end-users to automate and customize the Web

bolinfest/coffee-script 57

Unfancy JavaScript

bolinfest/immutable-thought-experiment 12

Thought experiment: leveraging static typing instead of new data structures to enforce immutability in JavaScript with Flow annotations.

bolinfest/bpftrace-vscode 3

VS Code extension for bpftrace (syntax highlighting only)

bolinfest/atom 2

The hackable editor

bolinfest/args4j 1

args4j

bolinfest/es-next-fun 1

Experiments with JS Transpilers

bolinfest/Adafruit_Python_LED_Backpack 0

Python library for controlling LED backpack displays such as 8x8 matrices, bar graphs, and 7/14-segment displays on a Raspberry Pi or BeagleBone Black.

bolinfest/arcanist-lint-test 0

Simple repo to test how Arcanist's linting engine works.

issue openedmicrosoft/vscode-oniguruma

remove oniguruma.patch?

The build instructions mention:

Run git apply oniguruma.patch - This is necessary until https://github.com/kkos/oniguruma/issues/192 is fixed.

That issue appears to be fixed. Can that instruction / patch file be removed if the hash for deps/oniguruma is updated past the point where the fix was applied?

created time in 19 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha d23b302d3e60764283e1351d74c1b71e75eac553

remove duplicate null check

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha e0fefd04747aec2843800befd8f25e958d519ddb

remove more unused code

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha a95a222e77b5a148284dadf882b21900f1bdc96a

remove dependency on nullthrows and remember to update yarn.lock

view details

push time in 24 days

issue commentNeekSandhu/monaco-editor-textmate

EncodedTokensProvider?

@NeekSandhu @vasiltabakov

I just got a demo working that uses vscode-textmate and vscode-oniguruma. It leverages EncodedTokensProvider:

https://github.com/bolinfest/monaco-tm/

vasiltabakov

comment created time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

Ah, the critical step I was missing was setting theme data. Now I have everything working and I tried to remove all of my scratchwork from earlier iterations:

https://github.com/bolinfest/monaco-tm/commit/ca4e82bc00a0ba22dbb8174b3ecbc9362bdf1d13

CitrusFruits

comment created time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha ca4e82bc00a0ba22dbb8174b3ecbc9362bdf1d13

clean up the demo now that it is working as intended!

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha d305813b6e01bb793719d2225a6b7e914a684675

EncodedTokensProvider works once theme data is loaded!

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha f257c636791353003801d4278e695584e37c13dd

specify color for constant.other

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha b5033530fb09d2db8928aa02ee93379d645235fa

add Python example

view details

push time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

Of note from https://github.com/NeekSandhu/monaco-textmate#credits:

99% of the code in this repository is extracted straight from vscode-textmate, which is MIT licensed. Other external licenses used can be found in ThirdPartyNotices.txt

CitrusFruits

comment created time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

OK, if you checkout https://github.com/bolinfest/monaco-tm/commit/bcea24a9dee009eab366e3eb32117b46899a097f and build and run the demo, you can see things working with Hack, which is a language for which no Monarch grammar exists.

Note that I am currently using these:

https://github.com/NeekSandhu/monaco-textmate https://github.com/NeekSandhu/monaco-editor-textmate

I believe https://github.com/NeekSandhu/monaco-editor-textmate/issues/11 provides some insight as to why my initial approach is not working.

CitrusFruits

comment created time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha bcea24a9dee009eab366e3eb32117b46899a097f

Improve quality of Hack example.

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha 8ea1ed8d56894ae47589bf7e5161e0ed2170f74c

Got things working with monaco-editor-textmate.

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha b05eb80f4accc5be5a47761d3393ea764a28c5e0

monaco.languages.TokensProvider experiment

view details

Michael Bolin

commit sha 9d4ceab3d9c032218fca441ca0860ca7fda40aba

Use MonacoWebpackPlugin to disable default language tokenizers. This was confusing things and explains why some languages, like HTML, appeared to work, but it wasn't because of the TextMate grammar! Got this idea by reading https://github.com/NeekSandhu/monaco-editor-textmate/blame/45e137e5604504bcf744ef86215becbbb1482384/README.md#L58-L59 Now nothing is syntax highlighted (e.g., neither Hack nor HTML work), so now we're sure our code is being used.

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha e69d8ba3bde855a717f2bbe96f0628e6df1ba355

Use MonacoWebpackPlugin to disable default language tokenizers. This was confusing things and explains why some languages, like HTML, appeared to work, but it wasn't because of the TextMate grammar! Got this idea by reading https://github.com/NeekSandhu/monaco-editor-textmate/blame/45e137e5604504bcf744ef86215becbbb1482384/README.md#L58-L59 Now nothing is syntax highlighted (e.g., neither Hack nor HTML work), so now we're sure our code is being used.

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha af05600e34dbf67f213a6abe4971629f367e9e84

Use MonacoWebpackPlugin to disable default language tokenizers. This was confusing things and explains why some languages, like HTML, appeared to work, but it wasn't because of the TextMate grammar! Got this idea by reading https://github.com/NeekSandhu/monaco-editor-textmate/blame/45e137e5604504bcf744ef86215becbbb1482384/README.md#L58-L59 Now nothing is syntax highlighted (e.g., neither Hack nor HTML work), so now we're sure our code is being used.

view details

push time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha adbc9eb24cd2a66e738d8408b0966211a9f300e5

monaco.languages.TokensProvider experiment

view details

push time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

This is not working correctly yet, but I think it's close: https://github.com/bolinfest/monaco-tm.

CitrusFruits

comment created time in 24 days

push eventbolinfest/monaco-tm

Michael Bolin

commit sha 0f56c779abee325cfea50a520e2453dd9302a5f0

Initial commit.

view details

push time in 24 days

create barnchbolinfest/monaco-tm

branch : master

created branch time in 24 days

created repositorybolinfest/monaco-tm

Attempt to get TextMate grammars working in standalone Monaco

created time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

I just discovered that @NeekSandhu, who created https://github.com/NeekSandhu/onigasm, also created:

https://github.com/NeekSandhu/monaco-textmate https://github.com/NeekSandhu/monaco-editor-textmate

Though unsurprisingly, they use onigasm rather than vscode-oniguruma.

CitrusFruits

comment created time in 24 days

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

OK, I did a bit of digging, which may hopefully save @alexdima some typing if he has time to chime in on this thread. I'm not sure if I have all this right because I haven't tried to write any code yet, but:

  • Microsoft/VS Code now does its own build of oniguruma for WASM: https://github.com/Microsoft/vscode-oniguruma. Note that the NPM module contains a pre-built version of of the WASM under release/onig.wasm for convenience. Further, note this package builds the WASM itself rather than depend on https://github.com/NeekSandhu/onigasm (which seems sensible from a security perspective). From the vscode-oniguruma README:

Oniguruma bindings for VS Code. This library is used in VS Code and is not intended to grow to have general Oniguruma WASM bindings.

It seems like vscode-oniguruma should be sufficient for Monaco's needs, but if you need to do other things with Oniguruma in WASM, you might still need https://github.com/NeekSandhu/onigasm.

  • There is also https://github.com/Microsoft/vscode-textmate, which appears as though it can take an object with the methods createOnigScanner() and createOnigScanner() (which could be implemented by the Node onigurma or the WASM vscode-oniguruma) and produce a "grammar."

  • In vscode-textmate/src/main.ts, we can find the definition of the IGrammar interface:

/**
 * A grammar
 */
export interface IGrammar {
	/**
	 * Tokenize `lineText` using previous line state `prevState`.
	 */
	tokenizeLine(lineText: string, prevState: StackElement | null): ITokenizeLineResult;

	/**
	 * Tokenize `lineText` using previous line state `prevState`.
	 * The result contains the tokens in binary format, resolved with the following information:
	 *  - language
	 *  - token type (regex, string, comment, other)
	 *  - font style
	 *  - foreground color
	 *  - background color
	 * e.g. for getting the languageId: `(metadata & MetadataConsts.LANGUAGEID_MASK) >>> MetadataConsts.LANGUAGEID_OFFSET`
	 */
	tokenizeLine2(lineText: string, prevState: StackElement | null): ITokenizeLineResult2;
}
  • If you look over in the VS Code repo at abstractTextMateService.ts, you can find:
    • The TMTokenization class, which takes an IGrammar and invokes its tokenizeLine2() method from its own tokenize2() method.
    • The TMTokenizationSupport class, which takes an instance of TMTokenization. It implements ITokenizationSupport, though it supports only the tokenize2() method: it throws if you invoke tokenize().
    • The ITokenizationSupport interface is defined in vscode/vs/editor/common/modes.ts:
/**
 * @internal
 */
export interface ITokenizationSupport {

	getInitialState(): IState;

	// add offsetDelta to each of the returned indices
	tokenize(line: string, state: IState, offsetDelta: number): TokenizationResult;

	tokenize2(line: string, state: IState, offsetDelta: number): TokenizationResult2;
}

If you explore the signatures of the methods of ITokenizationSupport here, it appears to function as the union of TokensProvider and EncodedTokensProvider in monaco.languages. As such, it seems like it should be possible to take the code that I've referenced here and create an appropriate adapter such that you can make use of monaco.languages.setTokensProvider(EncodedTokensProvider) in standalone Monaco.

CitrusFruits

comment created time in 25 days

issue commentyunabe/tslab

Disable ANSI colorization in output by default?

I am not using the stock Jupyter notebook/lab for my presentation layer.

I use https://www.npmjs.com/package/ansi-to-html to render ANSI output for errors, which works fine because you get the entire error at once. I do not believe it works well for streaming output, though. For example, in my original example, suppose you received the output in two chunks: "\u001b[33" and "m55\u001b[39m\n". How would you ensure it is displayed correctly as you receive each chunk of the stream?

It's doable, but it's not simple. Output that is free of ANSI characters is much easier to deal with because you can just keep appending to the innerText of the DOM element used to display it.

bolinfest

comment created time in a month

issue openedyunabe/tslab

Disable ANSI colorization in output by default?

If I run console.log(55), the Jupyter message I get back is a stdout stream with the contents "\u001b[33m55\u001b[39m\n" because of the ANSI escapes for colorization. I was hoping to get "55\n" just like I would if I did print(55) in a Python kernel.

created time in a month

issue commentmicrosoft/monaco-editor

Revisit WebAssembly to support TextMate grammars

Come to think of it: what is VS Code Online doing with respect to this problem right now? Is it falling back to Monarch grammars? (For example, are async and await failing to get highlighted as keywords in Python files in VS Code Online today?)

Or have some of these been changed to use the Semantic Tokens Provider API? https://code.visualstudio.com/api/references/vscode-api#DocumentSemanticTokensProvider

CitrusFruits

comment created time in a month

issue closedmicrosoft/monaco-editor

Revisit built-in support for TextMate grammars

Maintaining both a TextMate grammar for VS Code as well as a Monarch grammar is a lot of work. As a result, the Monarch grammar often lags (e.g., lack of Python 3 support) or is nonexistent (Hack). In the absence of an official TextMate-to-Monarch converter, bringing TextMate support to Monaco seems like the best solution.

The justification for requiring the use of Monarch grammars instead of TextMate grammars on the README seems to cite some outdated statistics. For example, it notes:

We have experimented with Emscripten to compile the C library to asm.js, but performance was very poor even in Firefox (10x slower) and extremely poor in Chrome (100x slower).

Looking at old issues, I see these stats date back to at least 2016:

https://github.com/microsoft/monaco-editor/issues/171

The README also notes:

We can revisit this once WebAssembly gets traction in the major browsers, but we will still need to consider the browser matrix we support, i.e. if we support IE11 and only Edge will add WebAssembly support, what will the experience be in IE11, etc.

Looking at the latest data, WASM appears to have fairly broad support today, though IE11 is admittedly a notable exception:

https://caniuse.com/#feat=wasm

In terms of implementing support for TextMate grammars, it appears that there are two possible paths for filling in the missing oniguruma functionality:

  • A "pure JS" polyfill like onigurumajs, as suggested on https://github.com/microsoft/monaco-editor/issues/722.
  • A WASM implementation. https://github.com/NeekSandhu/onigasm claims to be 2x slower than the native V8 implementation, which I think many would choose over trying to maintain two grammars.

I think it would be ideal to get something working and then give the client the option to specify either a TM grammar or a Monarch one. (Or if we go the WASM route, specify the preferred TM grammar and the Monarch one as a fallback in browsers that either do not support WASM / lack performant support for WASM.)

I am happy to help, but I would like to know what the team is open to so that I don't work on something that has no chance of being upstreamed.

closed time in a month

bolinfest

issue commentmicrosoft/monaco-editor

Revisit built-in support for TextMate grammars

@rcjsuen Whoops, thanks! Closing as a dupe of https://github.com/microsoft/monaco-editor/issues/1915.

bolinfest

comment created time in a month

issue openedmicrosoft/monaco-editor

Revisit built-in support for TextMate grammars

Maintaining both a TextMate grammar for VS Code as well as a Monarch grammar is a lot of work. As a result, the Monarch grammar often lags (e.g., lack of Python 3 support) or is nonexistent (Hack). In the absence of an official TextMate-to-Monarch converter, bringing TextMate support to Monaco seems like the best solution.

The justification for requiring the use of Monarch grammars instead of TextMate grammars on the README seems to cite some outdated statistics. For example, it notes:

We have experimented with Emscripten to compile the C library to asm.js, but performance was very poor even in Firefox (10x slower) and extremely poor in Chrome (100x slower).

Looking at old issues, I see these stats date back to at least 2016:

https://github.com/microsoft/monaco-editor/issues/171

The README also notes:

We can revisit this once WebAssembly gets traction in the major browsers, but we will still need to consider the browser matrix we support, i.e. if we support IE11 and only Edge will add WebAssembly support, what will the experience be in IE11, etc.

Looking at the latest data, WASM appears to have fairly broad support today, though IE11 is admittedly a notable exception:

https://caniuse.com/#feat=wasm

In terms of implementing support for TextMate grammars, it appears that there are two possible paths for filling in the missing oniguruma functionality:

  • A "pure JS" polyfill like onigurumajs, as suggested on https://github.com/microsoft/monaco-editor/issues/722.
  • A WASM implementation. https://github.com/NeekSandhu/onigasm claims to be 2x slower than the native V8 implementation, which I think many would choose over trying to maintain two grammars.

I think it would be ideal to get something working and then give the client the option to specify either a TM grammar or a Monarch one. (Or if we go the WASM route, specify the preferred TM grammar and the Monarch one as a fallback in browsers that either do not support WASM / lack performant support for WASM.)

I am happy to help, but I would like to know what the team is open to so that I don't work on something that has no chance of being upstreamed.

created time in a month

pull request commentmicrosoft/monaco-languages

Update Python grammar to include keywords introduced in Python 3

/cc @alexdima should be a non-controversial one? If I added too many comments, feel free to remove/edit as you see fit.

bolinfest

comment created time in a month

PR opened microsoft/monaco-languages

Update Python grammar to include keywords introduced in Python 3

This supports https://github.com/microsoft/monaco-editor/issues/1762.

Note the new Python 3 keywords are:

  • async
  • await
  • nonlocal

I also reorganized the list a bit because it seems like it contains a mixture of keywords and builtins (and self, which is neither...), so it is helpful to be specific to illustrate how to properly maintain the list.

+13 -7

0 comment

1 changed file

pr created time in a month

create barnchbolinfest/monaco-languages

branch : python3-keywords

created branch time in a month

fork bolinfest/monaco-languages

Basic colorization support for many Monaco Editor languages.

fork in a month

push eventbolinfest/vscode

Michael Bolin

commit sha b9f5b9eeb21c89420e65ea8dddfebf5c6d4eacc8

Ensure @rematch and nextEmbedded can be used together in a Monarch grammar. Similar to the repro case I created for https://github.com/microsoft/vscode/pull/90266, I created a local playground with the following: ```js const DEMO_LANG_ID = "demo"; const SQL_QUERY_START = "(SELECT|INSERT|UPDATE|DELETE|CREATE|REPLACE|ALTER|WITH)"; const languageConfiguration = { tokenizer: { root: [ [ `(\"\"\")${SQL_QUERY_START}`, [ { "token": "string.quote", }, { token: "@rematch", next: "@endStringWithSQL", nextEmbedded: "sql", }, ] ], [ /(""")$/, [ { token: "string.quote", next: "@maybeStringIsSQL", }, ] ], ], maybeStringIsSQL: [ [ /(.*)/, { cases: { [`${SQL_QUERY_START}\\b.*`]: { token: "@rematch", next: "@endStringWithSQL", nextEmbedded: "sql", }, "@default": { token: "@rematch", switchTo: "@endDblDocString", }, } } ], ], endDblDocString: [ [ "[^\"]+", "string" ], [ "\\\\\"", "string" ], [ "\"\"\"", "string", "@popall" ], [ "\"", "string" ] ], endStringWithSQL: [ [ /"""/, { token: "string.quote", next: "@popall", nextEmbedded: "@pop", }, ] ], }, }; monaco.languages.register({ id: DEMO_LANG_ID, extensions: ['.example'], }); monaco.languages.setMonarchTokensProvider(DEMO_LANG_ID, languageConfiguration); const value = `\ mysql_query("""SELECT * FROM table_name WHERE ds = '<DATEID>'""") mysql_query(""" SELECT * FROM table_name WHERE ds = '<DATEID>' """) `; var editor = monaco.editor.create(document.getElementById("container"), { value, language: DEMO_LANG_ID, lineNumbers: "off", roundedSelection: false, scrollBeyondLastLine: false, readOnly: false, theme: "vs-dark", }); ``` Without my change to monarchLexer.ts, I get this error in the console: > errors.ts:26 Uncaught Error: demo: cannot pop embedded mode if not inside one But with my change, I see a Python-esque multiline string literal with SQL syntax highlighting within it.

view details

push time in a month

pull request commentmicrosoft/vscode

Ensure @rematch and nextEmbedded can be used together in Monarch grammar

/cc @alexdima

bolinfest

comment created time in a month

push eventbolinfest/vscode

Michael Bolin

commit sha 4e52140427526276a1c5e191b6c4f74a74b71b8f

Ensure @rematch and nextEmbedded can be used together in a Monarch grammar. Similar to the repro case I created for https://github.com/microsoft/vscode/pull/90266, I created a local playground with the following: ```js const DEMO_LANG_ID = "demo"; const languageConfiguration = { // The main tokenizer for our languages tokenizer: { root: [ [ /(""")(SELECT)/, [ { "token": "string.quote", }, { "token": "@rematch", "next": "@endStringWithSQL", "nextEmbedded": "sql", }, ] ], ], endStringWithSQL: [ [ /"""/, { "token": "string.quote", "next": "@pop", "nextEmbedded": "@pop", }, ] ], }, }; monaco.languages.register({ id: DEMO_LANG_ID, extensions: ['.example'], }); monaco.languages.setMonarchTokensProvider(DEMO_LANG_ID, languageConfiguration); const value = `\ mysql_query("""SELECT * FROM users WHERE id = 4 """) `; var editor = monaco.editor.create(document.getElementById("container"), { value, language: DEMO_LANG_ID, lineNumbers: "off", roundedSelection: false, scrollBeyondLastLine: false, readOnly: false, theme: "vs-dark", }); ``` Without my change to monarchLexer.ts, I get this error in the console: > errors.ts:26 Uncaught Error: demo: cannot pop embedded mode if not inside one But with my change, I see a Python-esque multiline string literal with SQL syntax highlighting within it.

view details

push time in a month

create barnchbolinfest/vscode

branch : rematch-with-grammar-change

created branch time in a month

PR opened microsoft/vscode

Ensure @rematch and nextEmbedded can be used together in Monarch grammar

Similar to the repro case I created for https://github.com/microsoft/vscode/pull/90266, I created a local playground with the following:

const DEMO_LANG_ID = "demo";

const languageConfiguration = {
	// The main tokenizer for our languages
	tokenizer: {
		root: [
			[
				/(""")(SELECT)/,
				[
					{
						"token": "string.quote",
					},
					{
						"token": "@rematch",
						"next": "@endStringWithSQL",
						"nextEmbedded": "sql",
					},
				]
			],
		],
		endStringWithSQL: [
			[
				/"""/,
				{
					"token": "string.quote",
					"next": "@pop",
					"nextEmbedded": "@pop",
				},
			]
		],
	},
};
monaco.languages.register({
	id: DEMO_LANG_ID,
	extensions: ['.example'],
});
monaco.languages.setMonarchTokensProvider(DEMO_LANG_ID, languageConfiguration);

const value = `\
mysql_query("""SELECT
* FROM users WHERE id = 4
""")
`;

var editor = monaco.editor.create(document.getElementById("container"), {
	value,
	language: DEMO_LANG_ID,

	lineNumbers: "off",
	roundedSelection: false,
	scrollBeyondLastLine: false,
	readOnly: false,
	theme: "vs-dark",
});

Without my change to monarchLexer.ts, I get this error in the console:

errors.ts:26 Uncaught Error: demo: cannot pop embedded mode if not inside one

But with my change, I see a Python-esque multiline string literal with SQL syntax highlighting within it.

<!-- Thank you for submitting a Pull Request. Please:

  • Read our Pull Request guidelines: https://github.com/Microsoft/vscode/wiki/How-to-Contribute#pull-requests.
  • Associate an issue with the Pull Request.
  • Ensure that the code is up-to-date with the master branch.
  • Include a description of the proposed changes and how to test them. -->

This PR fixes #

+25 -15

0 comment

1 changed file

pr created time in a month

issue commentmicrosoft/TypeScript

Glob support for per pattern tsconfig configuration

I have an alternative proposal in https://github.com/microsoft/TypeScript/issues/37884 that I believe would cover this, and other use cases, more generally. Instead of having a configuration defined in terms of a glob, it is given a name, and then you can set options you want on for the configuration (i.e., they can even have the same, or overlapping, globs).

This is more consistent with the general idea of "opt vs. debug" builds.

mohsen1

comment created time in a month

issue openedtimocov/dts-bundle-generator

Erroneous complaint about include pattern

Bug report

When I run:

./node_modules/.bin/dts-bundle-generator -o /tmp/export.d.ts src/index.ts --project tsconfig.json

I get an error complaining about missing files:

Projects must list all files or use an 'include' pattern.

even though my tsconfig.json contains:

  "include": ["./src/**/*"],

which covers the files it claims are missing.

Input code

// place your code here

Expected output

// place your code here

Actual output

// place your code here

Additional context Add any other context about the problem here (CLI options, etc)

created time in a month

issue openedmicrosoft/rushstack

[api-extractor] follow dependencies in Yarn workspace

Please prefix the issue title with the project name i.e. [rush], [api-extractor] etc.

Is this a feature or a bug?

  • [x] Feature
  • [ ] Bug

Please describe the actual behavior.

I am trying to create a single .d.ts file for my project. My code is organized as a Yarn workspace. Each package within the workspace has its own tsconfig.json file, which makes use of "references" for intra-workspace dependencies.

It seems that this information is not used when api-extractor run is used on a .ts file in my workspace that has transitive deps on other packages in the workspace.

If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.

What is the expected behavior?

Ideally, this would "just work" as if all the .ts files were in the same package.

If this is a bug, please provide the tool version, Node.js version, and OS.

  • Tool:
  • Tool Version:
  • Node Version:
    • Is this a LTS version?
    • Have you tested on a LTS version?
  • OS:

created time in a month

issue openedmicrosoft/TypeScript

tsconfig.json should support multiple configurations

Search Terms

multiple configurations, transitive closure

Suggestion

When using multiple packages in a monorepo, it is common to have a tsconfig.shared.json that all packages extend in their individual tsconfig.json. The current system makes it difficult to support various build configurations across packages (such as "dev" vs. "prod").

Because a property named "config" seems redundant in a file named tsconfig.json, I'll borrow the term select from Bazel and propose the following new option in a tsconfig.json file for defining configurations:

// tsconfig.shared.json
{
  // Via "select", we define two configurations: "universal" and "modern".
  "select": {
    "universal": {
      "compilerOptions": {
        "target": "es3",
        "downlevelIteration": true,
      },
    },
    "modern": {
      "compilerOptions": {
        "target": "es2019",
      },
    },
  },

  // These compilerOptions are common to both configurations.
  "compilerOptions": {
    "sourceMap": true,
    "module": "esnext",
    "moduleResolution": "node",
    "lib": ["dom", "es5", "es2019"],
    "strict": true,
  },
}

To complement this, tsc would have to support a new --select flag:

# Assume tsconfig.json extends tsconfig.json and defines "include" and "references".
# This would build the modern configuration.
$ tsc --build --select modern -p tsconfig.json

Ideally, it would also be possible to parameterize paths such as outDir so that you could also define this on the base compilerOptions in tsconfig.shared.json:

"outDir": "./dist/${select}/",

though I haven't been able to get "outDir" to do what I want in tsconfig.shared.json in my own project, so there might be more work to do on that front.

Use Cases

I want to be able to have a shared tsconfig.json that defines multiple configurations in one place that can be shared across multiple modules, as opposed to the current situation where we need O(M ⋅ C) tsconfig.json files where M is the number of modules and C is the number of configurations. A detailed example is below.

Examples

I have a Yarn workspace where each package is under the modules/ folder, so my root package.json contains the following:

{
  "workspaces": [
    "modules/*"
  ],
  "scripts": {
    "compile": "tsc --build modules/*"
  }
}

I also have a shared.tsconfig.json in the root of my Yarn workspace where I define the "compilerOptions" that I want all packages in the workspace to use. (For example, I set "target": "es2019" in shared.tsconfig.json.) Each folder under modules/ contains its own tsconfig.json file that contains the line:

  "extends": "../../tsconfig.shared.json",

and there is also a "references" property with the appropriate list of relative paths to other packages in the workspace.

Ideally, each such tsconfig.json would contain only "extends" and "references", but it seems I have to redeclare "compilerOptions.outDir" and "include" in each of these files even though the values are the same in each one (["src/**/*"] and "./dist", respectively).

OK, so far, so good, but now I want to be able to build my entire Yarn workspace with a different set of compilerOptions, specifically:

"downlevelIteration": true,
"target": "es3",

Ideally, I would be able to specify this in one place and leverage the "references" I already had to define so I could compile one .ts file or package and all of its transitive deps with these compiler options. (I happen to be using ts-loader in Webpack, so my ultimate output is a single .js file, which perhaps biases my expectations here.)

Unfortunately, there does not appear to be any clean way to do that. I could go through and define a tsconfig.es3.json in each of my packages that looks like this:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "downlevelIteration": true,
    "target": "es3",
  },
}

though even if I did that, I'm not sure I could build all of my modules as ES3 with a one-liner as I did in my original package.json file. Now I'm faced with the additional incidental complexity of:

  • Maintaining O(M) tsconfig.es3.json files and ensuring all of them are in sync.
  • Introducing Lerna or some other tool to "walk my DAG" and run tsc -b -p tsconfig.es3.json or something like that.

With the --select proposal, I could avoid the extra tsconfig.json files and still build via a one-liner:

tsc --build --select universal modules/*

I would expect if any of the tsconfig.json files under modules/* did not define a "universal" configuration, the build command would fail (or at least the strictness should be configurable).

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [x] This feature would agree with the rest of TypeScript's Design Goals.

created time in 2 months

issue openedjupyterlab/jupyterlab

include IDisplayUpdate in IOutput definition?

https://github.com/jupyterlab/jupyterlab/blob/aeadf79f4c4002933dfee72519eb30be277dd808/packages/nbformat/src/index.ts#L523

If IDisplayUpdate should not be part of IOutput, then perhaps there should be a comment explaining why?

created time in 2 months

issue commentmicrosoft/monaco-editor

Update/create package.json for monaco-languages to support ESM

Alternatively, perhaps this file can just be renamed to have an .mjs extension and that will do the trick?

Currently, I am able to workaround this by using the experimental -experimental-loader and creating a custom loader, but that's a bit annoying:

export async function getFormat(url, context, defaultGetFormat) {
  if (url.endsWith('/monaco-languages/release/esm/python/python.js')) {
    return {
      format: 'module',
    };
  }
  return defaultGetFormat(url, context, defaultGetFormat);
}
bolinfest

comment created time in 2 months

issue openedmicrosoft/monaco-editor

Update/create package.json for monaco-languages to support ESM

This is an issue about the monaco-languages package.

I am trying to use the ESM version of one of the files while using ES modules (i.e., node --es-module-specifier-resolution=node --experimental-modules). Specifically, I am trying to do:

import { conf as stockPythonConfiguration, language as stockPythonLanguage } from "monaco-languages/release/esm/python/python"

Unfortunately, this does not work because the package.json for monaco-languages does not specify "type": "module". I suspect setting this would break things for other people, so perhaps there needs to be a separate monaco-languages-esm module with "type": "module" in its package.json?

created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

Oh, hm, I just realized that processId is unspecified, is that the issue?

bolinfest

comment created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

I also just tried this my local copy of pyls and it worked:

$ python3 -m pyls -vvvv --log-file /tmp/pyls.log < /Users/mbolin/src/test-lsp/initialize.rpc
Content-Length: 641
Content-Type: application/vscode-jsonrpc; charset=utf8

{"jsonrpc": "2.0", "id": 0, "result": {"capabilities": {"codeActionProvider": true, "completionProvider": {"resolveProvider": false, "triggerCharacters": ["."]}, "documentFormattingProvider": true, "documentHighlightProvider": false, "documentRangeFormattingProvider": true, "documentSymbolProvider": true, "definitionProvider": true, "executeCommandProvider": {"commands": []}, "hoverProvider": true, "referencesProvider": true, "signatureHelpProvider": {"triggerCharacters": ["(", ","]}, "textDocumentSync": {"openClose": true, "willSave": true, "change": 2, "willSaveWaitUntil": true, "save": {"includeText": true}}, "experimental": {}}}}/Users/mbolin/fbsource/xplat/vscode/vscode-extensions/pyls/VendorLib
bolinfest

comment created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

Here is a simple repro: https://gist.github.com/bolinfest/2474367e6f923fdb98df1c409616c8ac

When I pipe that to a simple LSP based off the code sample from https://code.visualstudio.com/api/language-extensions/language-server-extension-guide#explaining-the-language-server, I see a response written to stdout. When I try the same thing with Microsoft.Python.LanguageServer, I get no response.

bolinfest

comment created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

Ah, thanks, I forgot about the \r\n requirement, so this is almost definitely well-formatted...

bolinfest

comment created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

I just tried changing it to "trace": "verbose" (and Content-Length: 5717), but it still just hangs with no output.

bolinfest

comment created time in 2 months

issue commentmicrosoft/python-language-server

environment variable to enable logging

I am running Microsoft.Python.LanguageServer < initialize.json with the following as the contents of my initialize.json file, so I was hoping/expecting that a request from more data from the client would be written to stdout (or an error to stderr):

Content-Length: 5713

{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "initializationOptions": {
      "interpreter": {
        "properties": {
          "InterpreterPath": "/usr/local/bin/python3"
        }
      }
    },
    "rootPath": null,
    "rootUri": "file:///tmp",
    "capabilities": {
      "workspace": {
        "applyEdit": true,
        "workspaceEdit": {
          "documentChanges": true,
          "resourceOperations": [
            "create",
            "rename",
            "delete"
          ],
          "failureHandling": "textOnlyTransactional"
        },
        "didChangeConfiguration": {
          "dynamicRegistration": true
        },
        "didChangeWatchedFiles": {
          "dynamicRegistration": true
        },
        "symbol": {
          "dynamicRegistration": true,
          "symbolKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25,
              26
            ]
          }
        },
        "executeCommand": {
          "dynamicRegistration": true
        },
        "configuration": false,
        "workspaceFolders": true
      },
      "textDocument": {
        "publishDiagnostics": {
          "relatedInformation": true,
          "tagSupport": true
        },
        "synchronization": {
          "dynamicRegistration": true,
          "willSave": true,
          "willSaveWaitUntil": true,
          "didSave": true
        },
        "completion": {
          "dynamicRegistration": true,
          "contextSupport": true,
          "completionItem": {
            "snippetSupport": true,
            "commitCharactersSupport": true,
            "documentationFormat": [
              "markdown",
              "plaintext"
            ],
            "deprecatedSupport": true,
            "preselectSupport": true
          },
          "completionItemKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25
            ]
          }
        },
        "hover": {
          "dynamicRegistration": true,
          "contentFormat": [
            "markdown",
            "plaintext"
          ]
        },
        "signatureHelp": {
          "dynamicRegistration": true,
          "signatureInformation": {
            "documentationFormat": [
              "markdown",
              "plaintext"
            ],
            "parameterInformation": {
              "labelOffsetSupport": true
            }
          }
        },
        "definition": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "references": {
          "dynamicRegistration": true
        },
        "documentHighlight": {
          "dynamicRegistration": true
        },
        "documentSymbol": {
          "dynamicRegistration": true,
          "symbolKind": {
            "valueSet": [
              1,
              2,
              3,
              4,
              5,
              6,
              7,
              8,
              9,
              10,
              11,
              12,
              13,
              14,
              15,
              16,
              17,
              18,
              19,
              20,
              21,
              22,
              23,
              24,
              25,
              26
            ]
          },
          "hierarchicalDocumentSymbolSupport": true
        },
        "codeAction": {
          "dynamicRegistration": true,
          "codeActionLiteralSupport": {
            "codeActionKind": {
              "valueSet": [
                "",
                "quickfix",
                "refactor",
                "refactor.extract",
                "refactor.inline",
                "refactor.rewrite",
                "source",
                "source.organizeImports"
              ]
            }
          }
        },
        "codeLens": {
          "dynamicRegistration": true
        },
        "formatting": {
          "dynamicRegistration": true
        },
        "rangeFormatting": {
          "dynamicRegistration": true
        },
        "onTypeFormatting": {
          "dynamicRegistration": true
        },
        "rename": {
          "dynamicRegistration": true,
          "prepareSupport": true
        },
        "documentLink": {
          "dynamicRegistration": true
        },
        "typeDefinition": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "implementation": {
          "dynamicRegistration": true,
          "linkSupport": true
        },
        "colorProvider": {
          "dynamicRegistration": true
        },
        "foldingRange": {
          "dynamicRegistration": true,
          "rangeLimit": 5000,
          "lineFoldingOnly": true
        },
        "declaration": {
          "dynamicRegistration": true,
          "linkSupport": true
        }
      }
    },
    "trace": "off",
    "workspaceFolders": null
  }
}
bolinfest

comment created time in 2 months

issue openedmicrosoft/python-language-server

environment variable to enable logging

I am trying to use this language server outside of VS Code. I have an initial JSON-RPC message in a text file and I am using < to feed it to Microsoft.Python.LanguageServer, but the executable just hangs. It would be great if I could use an environment variable to enable logging and get some idea of what is going on.

created time in 2 months

issue commentnodejs/node

--es-module-specifier-resolution=node not working from v13.0.1

@guybedford when I create extensions.js as you describe and run:

$ cat extensions.js
// https://github.com/nodejs/node/issues/30520
require._extensions['.mjs'] = require._extensions['.js'];
$ node -r extensions.js --es-module-specifier-resolution=node --experimental-modules lib/server/main.js

I get:

internal/modules/cjs/loader.js:979
  throw err;
  ^

Error: Cannot find module 'extensions.js'
Require stack:
- internal/preload
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:976:15)
    at Function.Module._load (internal/modules/cjs/loader.js:859:27)
    at Module.require (internal/modules/cjs/loader.js:1036:19)
    at Module._preloadModules (internal/modules/cjs/loader.js:1292:12)
    at loadPreloadModules (internal/bootstrap/pre_execution.js:448:5)
    at prepareMainThreadExecution (internal/bootstrap/pre_execution.js:71:3)
    at internal/main/run_main_module.js:7:1 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ 'internal/preload' ]
}

what am I missing?

jaydenseric

comment created time in 2 months

issue commentmicrosoft/TypeScript

TypeScript fails to recognize variable can take on other union values when variable can be updated by a function called in a loop

Ah, and here's a fix without the getter (note the annotation when block is defined):

type Block = "a" | "b";

function exposeBug() {
    let block: Block | null = null as Block | null;

    // Do not read block directly: require callers to go through getter!

    const update = () => { block = Math.random() > 0.5 ? "a" : "b" };
    update();

    for (let i = 0; i < 3; i++) {
        switch (block) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}

exposeBug();
bolinfest

comment created time in 3 months

issue commentmicrosoft/TypeScript

import type can't be used with interface extends

Ah, though as a workaround I can do:

import type * as monaco from "monaco-editor";
type IViewZone = monaco.editor.IViewZone;

interface MyViewZone extends IViewZone {
  marginDomNode: HTMLElement;
}
mjbvz

comment created time in 3 months

pull request commentmicrosoft/TypeScript

Fix type-only imports in interface 'extends' and import=/export=

Ah, though as a workaround I can do:

import type * as monaco from "monaco-editor";
type IViewZone = monaco.editor.IViewZone;

interface MyViewZone extends IViewZone {
  marginDomNode: HTMLElement;
}
andrewbranch

comment created time in 3 months

pull request commentmicrosoft/TypeScript

Fix type-only imports in interface 'extends' and import=/export=

I just commented on #36478 as I don't think this fixes the issue when the type is another level deep because it appears I can do this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.IRange {
  marginDomNode: HTMLElement;
}

but not this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.editor.IViewZone {
  marginDomNode: HTMLElement;
}
andrewbranch

comment created time in 3 months

issue commentmicrosoft/TypeScript

import type can't be used with interface extends

I suspect it has to do with the depth into the namespace? It appears I could do this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.IRange {
  marginDomNode: HTMLElement;
}

but not this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.editor.IViewZone {
  marginDomNode: HTMLElement;
}
mjbvz

comment created time in 3 months

issue commentmicrosoft/TypeScript

import type can't be used with interface extends

This is marked "closed," but I am still seeing this issue on TypeScript 3.8.3.

TypeScript Version: 3.8.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) --> Search Terms: import type

Code

import type * as monaco from "monaco-editor";

// Trying to create a subtype of IViewZone that provides
// a guarantee that marginDomNode is not null.
interface MyViewZone extends monaco.editor.IViewZone {
  marginDomNode: HTMLElement;
}

Expected behavior: This should typecheck.

Actual behavior:

error TS1361: 'monaco' cannot be used as a value because it was imported using 'import type'.

24 interface MyViewZone extends monaco.editor.IViewZone {
                                      ~~~~~~

  src/zoneManager.ts:5:13
    5 import type * as monaco from "monaco-editor";
                  ~~~~~~~~~~~
    'monaco' was imported here.

Note that in the same file, I can do:

type ZoneWidget = {
  afterLineNumber: number;
  zone: monaco.editor.IViewZone;
};

so it is surprising that I can use monaco.editor.IViewZone in one place but not the other.

Playground Link: Unfortunately, I cannot repro in a playground as I would expect. Perhaps this is something specific to monaco-editor? For example, doing something analogous with the http Node built-in works fine:

https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=5&pc=2#code/JYWwDg9gTgLgBDAnmApnAVHAhgZzgCxhjDgDMoIQ4AiQ46gbgCgngA7GFKUrAYzQCyiAMIAbYCg4AlFAEcArihwwAglADmeFAA9ObACZ46YAHRiJ0uYuVrNcAN5M4zuGAowIvCKIBccZVDs6swAvkA

Related Issues: This one!

mjbvz

comment created time in 3 months

issue closedmicrosoft/TypeScript

TypeScript fails to recognize variable can take on other union values when variable can be updated by a function called in a loop

TypeScript Version: 3.8.3

Search Terms: loop, union, side-effect

Expected behavior:

TypeScript should recognize that cases "a" and "b" are reachable because update() could change the value of block to it. In fact, the only case that is not reachable is the null case, which is only one TypeScript thinks is reachable!

Actual behavior:

TypeScript believes block must be null and flags errors on cases "a" and "b" in the switch statement.

Code

type Block = "a" | "b";

function exposeBug() {
    let block: Block | null = null;
    const update = () => { block = Math.random() > 0.5 ? "a" : "b" };
    update();

    for (let i = 0; i < 3; i++) {
        switch (block) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}

exposeBug();

<details><summary><b>Output</b></summary>

"use strict";
function exposeBug() {
    let block = null;
    const update = () => { block = Math.random() > 0.5 ? "a" : "b"; };
    update();
    for (let i = 0; i < 3; i++) {
        switch (block) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}
exposeBug();

</details>

<details><summary><b>Compiler Options</b></summary>

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

</details>

Playground Link: Provided

closed time in 3 months

bolinfest

issue commentmicrosoft/TypeScript

TypeScript fails to recognize variable can take on other union values when variable can be updated by a function called in a loop

In case anyone else finds this and is looking for a workaround, I found that introducing a getter function seemed to work:

type Block = "a" | "b";

function exposeBug() {
    let block: Block | null = null;

    // Do not read block directly: require callers to go through getter!
    let getBlock = (): Block | null => block;

    const update = () => { block = Math.random() > 0.5 ? "a" : "b" };
    update();

    for (let i = 0; i < 3; i++) {
        switch (getBlock()) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}

exposeBug();
bolinfest

comment created time in 3 months

issue commentmicrosoft/TypeScript

TypeScript fails to recognize variable can take on other union values when variable can be updated by a function called in a loop

@j-oliveras Yes, I believe it is, though I think I'm 100 comments into that issue (which dates back to 2016?!) and I still haven't seen anything that looks like a suggested workaround. I was hoping to do something other than @ts-ignore, which seems heavyweight.

bolinfest

comment created time in 3 months

issue openedmicrosoft/TypeScript

TypeScript fails to recognize variable can take on other union variables when variable can be updated by a function called in a loop

TypeScript Version: 3.8.3

Search Terms: loop, union, side-effect

Expected behavior:

TypeScript should recognize that cases "a" and "b" are reachable because update() could change the value of block to it. In fact, the only case that is not reachable is the null case, which is only one TypeScript thinks is reachable!

Actual behavior:

TypeScript believes block must be null and flags errors on cases "a" and "b" in the switch statement.

Code

type Block = "a" | "b";

function exposeBug() {
    let block: Block | null = null;
    const update = () => { block = Math.random() > 0.5 ? "a" : "b" };
    update();

    for (let i = 0; i < 3; i++) {
        switch (block) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}

exposeBug();

<details><summary><b>Output</b></summary>

"use strict";
function exposeBug() {
    let block = null;
    const update = () => { block = Math.random() > 0.5 ? "a" : "b"; };
    update();
    for (let i = 0; i < 3; i++) {
        switch (block) {
            case null: {
                console.log('null case');
                break;
            }
            case "a": {
                console.log('a case');
                break;
            }
            case "b": {
                console.log('b case');
                break;
            }
        }
        update();
    }
}
exposeBug();

</details>

<details><summary><b>Compiler Options</b></summary>

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

</details>

Playground Link: Provided

created time in 3 months

issue commentprettier/prettier

Inconsistent ending for type

@bradzacher I feel like I am going to lose this battle, but nevertheless, I favor the consistency of "objects looking like objects" over "objects looking like interface". In the case of type Obj, using ; within the curlies makes it look like a statement, which it is not. So from my perspective, the status quo is the inconsistency!

vjeux

comment created time in 3 months

pull request commentbolinfest/serde-jsonrc

Switchable comma mode

So you could disallow trailing commas but still allow comments? That seems...arbitrary?

adetaylor

comment created time in 3 months

pull request commentbolinfest/serde-jsonrc

Allow \x and \v

Hmm, so to confirm, these are not allowed as part of the official JSON spec, correct? That is, I do not see them in Section 7 here:

https://tools.ietf.org/html/rfc7159

What is your motivation for this change? jsonrc is admittedly about making JSON easier for humans to author, but these changes seem more likely for the benefit of machine-generated JSON, which could use the existing \u escaping scheme instead, no?

adetaylor

comment created time in 3 months

issue commentmicrosoft/vscode

minor: Documentation copypasta bug

Also, is FoldingContext supposed to be an empty interface?

bolinfest

comment created time in 3 months

issue openedmicrosoft/vscode

minor: Documentation copypasta bug

The docs for FoldingRangeProvider appear to have been copied from DocumentColorProvider:

https://github.com/microsoft/vscode/blob/cdde27aea0816662a290b9aa6303fbfe907a5c1e/src/vs/editor/common/modes.ts#L1248-L1256

created time in 3 months

issue commentyarnpkg/yarn

Yarn outputs script meta-information to stdout instead of stderr

This doesn't answer the question of why yarn run writes to stderr rather than stdout by default. This is not particularly command-line friendly.

wcauchois

comment created time in 3 months

more